Posts tagged Bug
WordPress Google Form update – v0.22
0Yesterday I received a report from someone using WordPress Google Form that their checkboxes weren’t working. This was very confusing to me because last weekend I spent a bunch of time fixing and testing the checkbox problem.
It turns out the jQuery script which fixes the checkboxes to work with PHP was never running. Why wasn’t it running? Because jQuery wasn’t ever loaded. Why wasn’t jQuery loaded? Because wpGForm never loaded it! It turned out the website which reported the problem was using a theme that doesn’t use jQuery and therefore never loaded it.
Well the WordPress Google Form plugin, which needs jQuery, didn’t load it either. I (and I can only assume other people) was never seeing a problem because either the theme or another plugin was loading jQuery.
The v0.22 update corrects this problem which was somewhat of a corner case, but a problem none the less.
WordPress Google Form minor update – v0.21
3This morning I have updated WordPress Google Form and fixed a number of documentation problems and added one minor new feature. While I am not a big fan of Javascript Alerts, I had a request to allow a message to be displayed upon successful form submission. I have added a new parameter (alert=’message’) to the gform short code to enable this new functionality.
[gform form='https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dEYwbGNYVG9TRUhXellMaDBuZ1RQTHc6MQ#gid=0' confirm='http://localhost/?page_id=435' alert='You da man!']
The new release should appear in the WordPress repository immediately and as Dashboard update fairly soon.
Yet another update! WordPress Google Form v0.18 available
6I 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!
wpGForm Bugs in v0.15
1I 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.
WordPress Google Form v0.15 released
0This morning I fixed the problem with the default settings which caused any of the settings which are on by default, to be on no matter what. Even when the user would turn them off, the plugin would ignore the user setting which was being saved correctly, just ignored being ignored by the during the default check.
I also finished removing the jQuery-Validate plugin as it is no longer used as well as a bunch of debug code and functions which are no longer used. Updates should appear on your Dashboard soon and it is already available for download in the WordPress plugin repository.
WordPress Google Form Bug with default CSS
0There 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.
Quick bump to v0.14 for WordPress Google Form
0While 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.
WordPress Google Form v0.13 fixes “back” bug
0I 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.
Support for multi-page Google Forms?
5I received an email the other day about my WordPress Google Form plugin wondering whether or not it should work with multi-page Google Forms It hadn’t even occurred to me to test it as none of the forms I had needed myself were multi-page forms but my gut reaction was I didn’t think it would work.
I took a look at a multi-page Google Form and have determined that the current (v0.10) version of the WordPress Google Form plugin (aka wpGForm) will not work with multi-page forms. No real big surprise but I want it to be clear before someone else wastes their time trying to make it work.
From looking at the form code it may be possible to support multi-page forms in the future but it will require some additional jQuery scripting and more importantly, some time to dedicate to it. I hope to look at this soon but I have a couple of WordPress theme projects that I need to get off my plate before I can go back to wpGForm.
WordPress Google Form v0.10 released
0Yesterday I committed the final changes (and still missed a few typos – ugh) to the WordPress plugin repository. The v0.10 release addresses the problems with required fields on a Google Form. I’ve heard from several people who’ve told me this fixes the problems they were seeing but if you run into something, add a comment here and I’ll do my best to take a look at it.
Note: I’ve also changes the beta download link to resolve to the WordPress download so the beta is no longer available.
Recent Comments