Google Forms Date and Time Fields

At some point Google added support for Date and Time fields to Google Forms.  When building the form, the Question Type now includes the “Date” and “Time” options.  These are pretty handy options because requesting dates and times from users is a very typical requirement.

GForm_SS_83Earlier this week a user posted on the WordPress Support Forum asking why their date field didn’t look the same on their web site using the plugin as it did when looking at the form within Google Drive.  The user assumed the plugin was doing something to change the form inputs.

The Google Forms plugin does not add or remove input fields (except the optional CAPTCHA field) – it simply retrieves the HTML from Google, strips of the content which falls outside of the form itself, and renders it within the WordPress context.

So why would the input fields be different when the form is viewed within WordPress versus viewing the Google Drive version of the form?

GForm_SS_85

Google Form in WordPress

GForm_SS_84

Native Google Form viewed in Firefox

Native Google Form viewed in Chrome.

Native Google Form viewed in Chrome.

As seen in the images above, the native Google Form is rendered differently in Google Chrome than it is in Firefox.  Having done some work with jQuery Mobile I know that Chrome recognizes HTML5 input tags where as Firefox does not.  I suspected this was the source of the problem.

I ran a couple of tests playing with cURL commands and different user agent strings and sure enough, Google is returning different HTML for different user agent strings.  I quickly added the user agent string to the parameters I was passing to the HTTP API to retrieve the HTML from Google and sure enough, the form, when viewed in Chrome, now matches what is seen when viewing the native form.

GForm_SS_87

I have committed the change to the plugin to pass the user-agent through the HTTP API.  This change will allow Chrome users to see the forms as intended.

What about other browsers?  Unfortunately the trick Google uses to add the date picker to the forms when viewed in Firefox, IE, or others which don’t recognize HTML5 input, or that Google thinks don’t support HTML5 input, isn’t easily passed through the HTTP API.

For now, I don’t see any simple way to solve this problem.  Over time it should go away as more browsers support HTML5 input types but for now, it is a limitation for non-Chrome users.  I fully expected it to work on the iPhone as the iOS browser is fully HTML5 compliant for input but it too is sent separate select inputs for the various fields.  I am not sure why, but it appears Google is treating their own browser differently than all other browsers.

The user-agent addition will be added to the next version of the plugin which will go out shortly with another validation bug fix.

 

 

Google Forms v0.64-beta-3 available

This evening I uploaded v0.64-beta-3 of Google Forms.  This version adds a check for the WordPress HTTP API cURL transport and issue a notification if it isn’t present.

There was a substantial change to the WordPress HTTP API between 3.6.1 and 3.7.  I don’t know the full details of the change but what I found in pretty extensive testing is the streams and fsockopen transports work in 3.6.1 with the Google Forms plugin but from 3.7 and later, they do not.

However, the cURL transport does work and as long as it is available, the plugin will work as it always has.  The problem is I cannot find any way to work with sites that don’t have the cURL transport available so I have added this check and issue a notice when it isn’t present.

GForm_SS_70

 

Please download and test out this beta version and report any issues found.

Google Forms Beta (428 downloads)

Chasing Checkbox Support

For the past couple of days I have continued to look at the problem I wrote about with Google Forms and Checkboxes with PHP 5.4 and PHP 5.5.  It turns out, that it really isn’t PHP version related, at least I don’t think so.  It is WordPress related as near as I can tell.

As I’ve written before, I love VMware Workstation as it allows you to create virtual machines for very specific purposes, use them as long as needed, then put them away until needed again.

I created an Unbuntu VM to play with Ruby on Rails a couple months ago so I decided to check what version of PHP it had running.  Lo and behold, it had PHP 5.5.x running so it was a good platform to further test potential solutions for my checkbox problem.  My Windows environment is running PHP 5.3.3 and is still running WordPress 3.6.1 (don’t ask why but it proved to be very useful that it was).

I quickly set up WordPress 3.8 on Ubuntu and sure enough, submitting the form failed.  The exact same plugin code on my Windows VM submitted correctly.  I continued to dig through my code and eventually into WordPress itself trying to see what was different.

I eventually started looking at the source to wp_remote_post() and decided to identify which transport was being used.  On Windows WordPress was using cURL but on Ubuntu it was using Streams.  Ah-ha.  Since the WordPress HTTP API abstracts the details of the transports away from the application, it shouldn’t matter but it seems to.  I continued digging.

Using an advanced feature of WordPress Google Form to control transports, I disabled the cURL transport on the Windows machine and much to my surprise, the form still submitted correctly.  Now this is odd.  So I then installed cURL on Ubuntu and the form submitted correctly.  The good news is there at least appears to be a solution although I’d prefer to not have cURL be a requirement.

Now what was different?  I started looking into WordPress’ class-http.php file (which defines the WP_Http class) and noticed that the file on Windows was very different than the file on Ubuntu.  Looks like something changed between 3.6.1 and 3.8.1.

I decided to download the 3.6.1 and 3.7.1 releases from the WordPress archive and do some tests on Ubuntu where it is trivial to switch between WordPress releases.

To add a little more information, I did some testing with older versions of WordPress in combination with the http_api_transports to force a specific transport (‘streams’, ‘fsockopen’, and ‘curl’).  I found the following results:

WordPress 3.6.1 WordPress 3.7.1 WordPress 3.8.1
cURL Success Success Success
fsockopen Success Fail Fail
streams Success Fail Fail

Something clearly changed with the streams and fsockopen transports between 3.6.1 and 3.7.1.  A diff of the class-http.php file shows the change was substantial as the files are significantly different.

At this point I have concluded that my plugin will only work with sites where cURL is available.  I will probably release a version which displays a warning on the Dashboard if cURL is not available and that usage of the plugin is not recommended.

Another goofy e-mail from GoDaddy

I had another go-round with GoDaddy yesterday which resulted in another goofy e-mail.  I posted the fsockopen() example they had asked me to which timed out and GoDaddy responded with this:

Dear Mike,

I sincerely apologize for any confusion or frustration. You will need to specify the proxy in your coding. Applications that need to make outbound connections (port 443) will need to be made “proxy aware”. This will require additional coding to varying degrees, depending on the application. You will need to know the ip address and port of the proxy server in order to correctly modify your code. The ip of the proxy server is 64.202.165.130 and connections will be made on port 3128.

You will need to use this when coding with PHP:
curl_setopt ($ch, CURLOPT_HTTPPROXYTUNNEL, TRUE);
curl_setopt ($ch, CURLOPT_PROXYTYPE, CURLPROXY_HTTP);
curl_setopt ($ch, CURLOPT_PROXY, http://64.202.165.130:3128);
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE);

I hope this information helps.

Please let us know if we can assist you in any other way.

Sincerely,
Lindsay C.
Online Support Representative

Right back to the cURL requirements which really don’t make any sense for fsockopen().  It really doesn’t matter as I chnaged the code which manages the Google Maps so it no longer needs it.

More on Phoogle & Google Maps

The members of the WordPress Hackers mailing list are really helpful and usually a very clever bunch.  I posted my dilema last night and received a couple suggestions, one of which was to abandon cURL and use Snoopy because it is embedded with WordPress and therefore would always be avaialble.

Sounds like a good idea so I check it out.  While I don’t care for the way the class is implemented (direct access to class variables), it if works, I don’t really care.  So I set it up and sure enough, it works in my development area.  Off the production server and nope, it doesn’t work either.  Snoopy depends on fsockopen which GoDaddy says is supported on all PHP hosting plans but it times out so I am guess what they have stated in their help system isn’t true.

Now I am not sure what to do other than to pursue a Javascript solution.  GoDaddy is quickly going on my “less than happy with” list.  I wonder if a Linux server would be any easier?

Demo Site is running … sort of

The nice folks at WinSwim are interested in what I am doing with this plugin and have offered to host a demo site.  You can find it at:  http://wp.winswim.com  The demo site is running for the most part, if you are interested in trying it out, go ahead and register with the demo site then drop me an e-mail so I can change your permissions so you can actually do something other than register sample swimmers.

I say the demo site is running “sort of” because just about everything is working although there are a few bugs I know of (e.g. defining age groups).  The one thing which isn’t working and it is driving me nuts is the ability to display a Google Map.  This is a really nice feature that my own team used quite a bit this year.

I have encapsulated a class called Phoogle within wp-SwimTeam and it worked just fine in my development area and on the MacDolphins site.  Phoogle relies on a PHP configuration option known as allow_url_fopen which basically allows PHP to open a web page on an external site and read the content like it would a local file.  It’s a nice feature but one that a lot of web hosting providers turn off.  In fact, the host for the demo site has it turned off.

There is another technology called cURL which for all practical purposes, accomplishes what allow_url_fopen does although it is a little more involved.  I enhanced Phoogle to use cURL if allow_url_fopen is disabled and it worked just fine in my development area.  Great!  The change was pretty simple too.  Uploaded to the production server and nothing.  It doesn’t work there.  It turns out that GoDaddy (the web hosting provider) has a goofy cURL implementation which requires the use of a proxy.

After a much trial and error and a couple e-mails with GoDaddy support, all I have accomplished is a partial cURL request.  I am unable to get a complete response which prevents the map from being displayed.  I then got another e-mail from GoDaddy telling me that cURL is only supported on their Linux hosting environments not under Windows (even though it is enabled in PHP.ini).  Bleh.  ;-(

I think for now when I find a short code, I will check the allow_url_fopen setting and if it is off, will issue a warning during the short code processing.  There is probably a way to interact with the Google Maps API via Javascript, I guess I will need to look into that.  It is really too bad, the Phoogle solution was really simple to use.