In the process of working with a user providing a Dutch translation, I found a number of strings which were not properly set up for language translation. This build provides no new functionality, only changes to support translation.
This build also replaces the French translation files with new ones as the files in the release could not be opened with Poedit nor would they be loaded by WordPress. Not sure what happened but the files were corrupt.
Note: Updated to beta-3 late in the afternoon on 12/30.
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.
What? Another beta release? Yes. A few weeks ago I had a report from a user who ran into a problem with WordPress Google Form running under PHP 5.4.4-14+deb7u2. None of the values in the form were being submitted to the target spreadsheet. The user was able to resolve the problem by changing how I was calling wp_remote_post() and sent me a DIFF file.
Unfortunately I had already started working on the changes I made to support multiple form instances (v0.61, v0.62) and the diff file couldn’t be applied to my source tree. I then forgot about it in my effort to get v0.61 out which had a number of other fixes in it that were affecting quite a few people.
Over the weekend I received a couple more help requests from people who had forms submitting that didn’t result in any data in the spreadsheet OR if the fields were required, messages indicating they had unanswered questions.
In looking at one of these sites in detail, everything looked correct on the WordPress side. This site has the Suhosin security module installed. I’ve run into Suhosin before but I couldn’t find any comments in my code nor any references to it on my web site. I am guessing that I was never able to fix the problem when I ran into it previously. In reading about Suhosin again, I recalled the patch which was sent to me a couple weeks ago.
My suspicion is that the way I was constructing the arguments to wp_remote_post() isn’t palatable to some versions of PHP. I decided to implement the changes that the patch had incorporated and see if it would address the problem. The change involves constructing the body argument as an array instead of a long URL formatted string. This is the right way to do it and it makes the code a little cleaner when needing to look at the parameters passed to wp_remote_post().
I was able to incorporate the patch by manually finding the corresponding source code lines in my current version and accounting for the changes I have made in the past month and get a beta release together fairly quickly. This fix allows the test form on the sites (one running PHP 5.4.6, one running PHP 5.3.10-1ubuntu3.8 with Suhosin-Patch).
If you want to try out this latest version, I would appreciate any feedback.
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.