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.
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.
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.
I’ve been out of pocket for the past few weeks, for anyone who has submitted a bug or help request, I apologize. I am back in North Carolina and have some time to address some of the questions and help requests which have queued up since before Christmas. I have answered a few Email Users and WordPress Google Form questions in the WordPress Support Forum but if you haven’t heard back from me, don’t hesitate to ping me again.
After a couple days of testing and five beta releases, I have released WordPress Google Form v0.61. This build supports multiple instances of the same form on a single page.
Why would you do this? It turns out, it is a fairly common request. A number of people have uses of the same form where some of the fields are hidden and preset (both features were added fairly recently) which allows them to present the form in different ways with seeded input while allowing the user to complete the rest. Because the form instances are all based on the same Google Form, they will have the exact same entry elements with the exact same attribute IDs. HTML does not allow multiple elements to have the same ID attribute, the behavior is unpredictable.
To support this new feature, a new parameter, uid, has been added to the wpgform shortcode. The uid parameter can be set to any string which is legal for an HTML element ID attribute. When the Google Form is processed, all of the attributes are modified to include the uid parameter to ensure they each have a unique value.
[wpgform id='879' uid='B-']
This release also addresses some issues with missing CAPTCHAs which would happen under certain circumstances. The jQuery generation is much cleaner now as well.
Another beta update, #5, for WordPress Google Form v0.61. This update fixes a couple more issues with validation which resulted in some extra jQuery content that was malformed. It only happened IF validation was enabled but no custom validation rules were defined.
I have just uploaded beta-4 of WordPress Google Form v0.61. This build corrects a couple more jQuery issues when using multiple instances of a form on the same page. In order to use multiple instances of the same form on a single page, you must use the uid parameter with the wpgform shortcode. Usage of this new parameter is outlined in the v0.61-beta-1 announcement.
The uid parameter is not supported in the deprecated gform shortcode.
Please download and test this beta release, all feedback is much appreciated.
The second beta build of WordPress Google Form v0.61 is now available. This beta build addresses some jQuery syntax errors introduced in the process of supporting multiple form instances. It also addresses a bug where the CAPTCHA would not be output as part of the form under certain circumstances.
Please download and test this new build if you have time and report anything which isn’t working.
About a week ago I was approached with an interesting problem. A user wanted to have the same form on single page three times. Three instances of the same form. Each instance would have some hidden values to determine which form was submitted.
The problem was by putting the same exact form on the page multiple times, a lot of the content (id and name attributes) was duplicated and as such, caused problems upon submission or even trying to move from field to field on the form. The current (v0.60) version of the plugin is effectively broken for multiple forms except in the simplest of cases (no CAPTCHA, validation, presets, etc.).
I’ve come up with a solution that needs some testing. I’ve added a new short code attribute to the wpgform shortcode which takes a string value and uses it as a unique identifier to ensure the replicated fields are actually unique in the source HTML.
In the image below you can see the text “B-” has been prepended to the id attribute for the form tag and an input tag. The “B-” was the value of the uid parameter in the shortcode for the form.
[wpgform id='879' uid='B-']
Download this beta version and run it through its paces. The ripple effect of this change across the code was pretty significant so I’d like to make sure it didn’t break anything.