Google Forms v0.65-beta-1 available

Shortly after releasing v0.64 I received a report of data corruption from a Google Forms user.  I took this report very seriously and immediately reverted the stable tag for Google Forms back to v0.63 while I looked into this users report.  The last thing I wanted to do was introduce a bug which resulted in corrupted posts.

I spent some time looking through my plugin code and tried a couple experiments but could not replicate the behavior the user reported.  My gut feel was we’re dealing with a plugin conflict however it is hard to know for sure.

The user and I ended up swapping some email and I got a list of plugins they were running.  I initially thought I would try and replicate their problem by installing the same set of plugins but quickly figured out that wasn’t possible.  Nor was it possible to examine all of the code for the plugins looking for what I suspected was a conflict in a “save_post” action or call to wp_update_post().

In doing some research I learned (unfortunately I can’t find it in the Codex) that beginning in WordPress 3.7 there is a new save_post action for Custom Post Types:  save_post_{$post_type}  Whoo-hoo!  This didn’t exist when I originally wrote Google Forms, so my plugin, much like many other plugins which define Custom Post Types, define a save_action which then has to determine if the post is relevant to the plugin or not before doing anything to it.

I quickly implemented the new action and removed the old action and Google Forms is behaving as it should in my testing.  I have uploaded this latest beta to my site and beat on it a bit and cannot corrupt any data.  I am very confident now that Google Forms should never touch anything other than it’s own post data.

Because of the reported corruption, I would encourage beta testers to backup their database before installing this update JUST TO BE SAFE but I think the corruption risk is very low.  Please let me know if you run into anything unusual.

In this v0.65 beta I have also changed the name of the plugin from “WordPress Google Form” to “Google Forms” as it is more representative and the plugin repository now prohibits the use of “WordPress” in a plugin name.  There is a chance you’ll have to reactivate the plugin depending on how you install this beta.

Google Forms Beta (308 downloads)

Google Forms v0.64 released

I did some additional testing with UTF-8 characters over the weekend and everything is working as expected.  With no known issues outstanding I have released v0.64 this morning.  You can find the update on your Dashboard or download it from the WordPress Plugin Repository.

  1. Fixed a number of strings which were missing translation wrapper functions.
  2. Reverted to manually constructed body parameter for wp_remote_post() to allow checkboxes to be properly passed to Google.
  3. Fixed warnings generated by calls to static functions which were not declared static.
  4. Added check for HTTP API cURL transport and issue a warning when not present. There was a change between WordPress 3.6.1 and 3.7 to the WordPress HTTP API and the streams and fsockopen transports are unable to post form values back to Google using wp_remote_post().
  5. Added a setting to allow hiding the cURL transport missing message on the Dashboard.
  6. Added a check to ensure jQuery script isn’t output more than once.
  7. Remove hook into “the_content” to reduce potential conflicts with other plugins (e.g. WordPress SEO plugin by Yoast).
  8. Added placeholders for some of the form fields when defining a Form within the UI.

Google Forms v0.64-beta-7 available

This afternoon I released beta-7 of Google Forms v0.64.  I expect this to be the final beta release.  It contains a few minor fixes, most notably the warning from the cURL check regarding calling a non-static function statically.  Additionally, some new “placeholder” information has been added to the Form Definition form which disappears when the user starts entering text into the field.

Google Forms Beta (308 downloads)

Google Forms v0.64-beta-6 available

I have just released beta-6 of Google Forms v0.64 which is a CRITICAL update for anyone who loaded beta-5.  Beta-5 had a serious bug which if you had defined more than one form using the Dashboard UI, would corrupt the content of all of the saved forms so every form would display the same content.  Beta-6 fixes this issue!

Google Forms Beta (308 downloads)

Google Forms v0.64-beta-5 available

2/14/2014 Update:  If you have more than one form defined, do not use beta-5, there is a serious bug which corrupts the content of the defined forms so they all contain the same data.

Beta #5 of Google Forms v0.64 is now available for testing.  This update addresses a plugin conflict between Google Forms and WordPress SEO plugin by Yoast.  The new implementation removes the hook into the_content which is a much more robust solution.

Google Forms Beta (308 downloads)

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 (308 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.

Google Forms, Checkboxes and PHP 5.4 or 5.5

WordPress Google Form v0.63 introduced a change  which allowed the plugin to work on newer versions of PHP, notably 5.4 and 5.5.  Unfortunately that change has broken support for checkboxes.

For those who are new to the plugin or never needed to know how it worked, what the plugin does is retrieve the HTML for the form from Google and render it within the context of WordPress.  When the form is submitted, it is actually submitted within the context of WordPress.   The data is collected by the plugin and then submitted to Google.  The retrieval from and submission to Google is done with the WordPress HTTP API.  In particular, the wp_remote_get() and wp_remote_post() functions are used to retrieve and submit the form.

To complicate the problem further, Google uses Python as the backend for their form processor where as WordPress uses PHP.  For the most part, the fact that they are based on different scripting languages isn’t a big deal.  Until you get to checkboxes.  Checkboxes in Python are handled differently than they are in PHP.

I had solved the compatibility problem a couple years ago (see this thread on the wp-hackers mailing list) using a small jQuery script which fixed the form variables on the WordPress side and manual construction of the body parameter for wp_remote_post() when submitting the data to Google.  This solution worked fine until I received a bug report that nothing was being submitted on a site which was running PHP 5.4.x.

Fortunately the user who encountered the problem provided me with a patch that I was able to fold in which changed the way the body parameter was constructed (array instead of a string) which worked with PHP 5.4.x and also worked with older versions.  However, I didn’t test it thoroughly as I have had several reports that checkbox content was not being submitted correctly.  Uh-oh.  I was able to verify the problem fairly quickly and was able to push out a version which essentially reverts how the body parameter is constructed (string instead of an array).  The problem is, this build doesn’t work with newer versions of PHP.

I have PHP 5.5 running on an Ubuntu virtual machines for testing and so far, I have not found a solution which (a) works with PHP 5.5. and (b) submits checkboxes correctly.

Stay tuned.

WordPress Google Forms v0.64-beta-2

This evening I released beta-2 of the upcoming v0.64 release of WordPress Google Forms.  This build addresses a problem recently reported on the Support Forum where the responses for checkboxes wasn’t being recorded properly.

I was able to verify this problem using one of my test forms and began looking into it.  It turns out, the changes made in v0.63 to allow the plugin to work with later versions of PHP 5.4 breaks the ability to uses checkboxes.  This build employs a similar method of submitting parameters to Google that versions prior to v0.63 did.

Handling checkboxes has long been a challenge due to the different ways which Python (used by Google) and PHP (used by WordPress) handle the assignment of checkbox values to a named parameter.

Please download this build and test and let me know if you run into any issues.

Google Forms Beta (308 downloads)

WordPress Google Form v0.64-beta-1 available

This morning I posted the first beta of WordPress Google Form v0.64.  There is no new functionality in this version, it just addresses a bunch of strings which were not properly set up for language translation.

If you want to provide a language pack for WordPress Google Form, this is the best version to work from.  I am currently working with a user who is working on a French translation.

Google Forms Beta (308 downloads)