I have just released another update to the WordPress Google Form plugin. Within the HTML code that Google generates for their forms, each input field has unique identifier (e.g entry.0.group, entry.47.group, entry.6.single, etc.). There was a bug in the Regular Expression which incorrectly handled these identifiers when then had more than one digit. This bug is fixed in v0.17.
Why do the identifiers need to be processed? The need to “massage” the identifiers is due to the fact that WordPress is based on PHP and Google Forms are processed by Python. The two languages handle passing form parameters slightly differently. When the form is submitted on the WordPress side, the periods in the id are translated to underscores by PHP. Inputs like check boxes which may contain multiple values are handled using arrays in PHP where as Python allows the use of the same identifier multiple times. In order to submit the form values to Google, any value received as an array must be converted to a multi-value and the underscores need to be translated back to periods so they match the Python script on the Google side which actually processes the form and stores the result in a Google Spreadsheet.
There was a mistake in the logic which transforms the identifiers from PHP syntax to Python syntax. It didn’t correctly handle more than one digit in the identifier resulting in the wrong identifier names being sent to Google. This also caused loss of input values when a required field was not supplied.
Hopefully this will be the last problem!
This morning I uploaded a new version of my WordPress Google Form plugin. This update addresses the three items I noted in this post. I also expanded the Test Bed Form I have been using to develop and test the plugin. If you’re curious, I have added the form to a page on this site. If you run into a combination that isn’t working and I haven’t accounted for it in the test bed, please let me know and I’ll update my form.
I think I finally have Check Boxes working correctly. They were a challenge because how PHP (which WordPress uses) pass arrays of information and Python (which Google Forms use for processing) are very different. Thanks to a tip on the WordPress Hackers Mailing List to a utility called http://httpbin.org I was able to get my plugin to pass the parameters as Google expects them and everything seems to be working correctly. The update should appear in your WordPress Dashboard fairly soon.
I have been alerted to a couple of bugs in the current (v0.15) version of wpGForm that I am working on fixing.
- Select boxes do not retain their value when going back on multi-page forms. I’ve already fixed this problem in my development build.
- Check boxes are not passing their values correctly.
- Sometimes Radio buttons do not retain their values when going back on multi-page forms.
This third item is proving difficult to track down. It is odd that some questions with radio buttons work fine going back and forth between pages but others do not. If I can fix the check boxes this morning I will likely release an update that addresses the first two bugs and keep working on the third problem.
There is a bug with the current (v0.14) version of WordPress Google Form in that it will always load the default CSS that is shipped with the plugin. Using the setting to disable loading the default CSS is not saved so it is never turned off. I am looking into this issue and will post an update as soon as it is fixed.
While looking at a CSS styling problem for someone I encountered a minor bug on the Options page. The plugin wasn’t picking up the default options correctly and in some cases a PHP array index warning would appear on the Options page. This bug has been fixed and I’ve released v0.14. You can download it from the WordPress plugin repository or update it from the Dashboard.
I have just committed v0.13 to the WordPress plugin repository. An update should appear in your WordPress Dashboard fairly soon. This update fixes a problem when using multi-page Google Forms which have radio buttons and check boxes on them. When the “Back” button was selected to view the previous page of the form, the previously selected values were not retained. This bug has been fixed and the “Back” and “Continue” buttons now work as expected.
This morning I fixed a bug which occurred when the default CSS was not enabled (which it isn’t by default). When the default CSS was not enabled, the jQuery Validation plugin wasn’t loading and then the jQuery script that initialized the validation would fail.
If you downloaded the beta prior to 10:00 EDT on 10/7, you should download it again and re-install.
This afternoon I spent some playing with a jQuery Form Validation plugin to determine if it will help me resolve the issue with required fields. The initial results look fairly promising as I was able to tag a couple fields on a test form and they were flagged when I submitted it.
In the image above, the jQuery Validation plugin added the “Thus field is required” when I submitted the form with those fields empty. This is exactly the behavior I want, the challenge now is to scale my Proof of Concept (PoC) to work in the generic case of the plugin. The Google form defines a block for each input field and the class the denotes a field as required is assigned to one of the DIV blocks that wraps the label and form element (e.g. INPUT or TEXTAREA tag) as opposed to the form element tag itself. This makes finding the required elements a little tricky.
The real challenge I think will be input groups (e.g. radio buttons and check boxes). I need to do some jQuery research before I have a solution but assuming I can figure out which elements to select, I believe this will solve the problem with required fields.
Google forms allow fields to be designated as required. When running the form using the standard Google URL, the form will be validated and presented back to the user if any of the required fields are not entered. There is an issue (aka bug) with required fields in the current version of the plugin.
If a user submits a form that is embedded in WordPress using the plugin, because there are missing fields the form processing does not complete. There is no indication for the user that something is wrong, the form is simply presented again without any of the fields having data in them.
To resolve this I am looking at doing form validation on the client side using a jQuery plugin. Hopefully I will have this resolved fairly quickly as I need this to work correctly for my own project. My testing didn’t take into account a user not completely the form correctly. Oops. This bug affects all versions of WordPress Google Form up to and including v0.9.
I have just committed v0.5 of the WordPress Google Form plugin. It addresses the problem with the Tabs on the Settings page not working correctly. It turns out that I had a couple of problems which were masked by the theme I was using. I have moved my development environment back to the stock Twenty-Eleven theme and turned off all other plugins.
By doing this I determined that the jQuery UI libraries I expected to be loaded, were in fact, not loaded at all. They were being loaded by the theme! Once I got the libraries loaded correctly the Tabs started working but they didn’t have the proper styling. WordPress doesn’t appear to include the jQuery UI CSS so I ended up loading it from Google’s CDN.
Everything seems to be working correctly now, v0.5 should appear as an update shortly if it hasn’t already.