Ugh. Google has made the process of using multi-page forms much harder than it used to be. In the older version of Google Forms the values were passed from one page to another in an array.
In the new version of Google Forms the data is still passed from page to page in a variable (called draftResponses) however PHP sees this data as a string instead of an array so the code which reformats the array from a PHP style (which WordPress uses) to a Python style (which Google uses) doesn’t run.
It looks like I will need to parse the string into a PHP array and then encode the array to be compatible with Python. As I said, ugh.
For a while I have wanted to have a log of form submissions. My interest in this has mostly been to understand the source of spam submissions but there are other reasons too. With all of the changes Google Forms have undergone recently, this seemed like a good time to add this functionality as I chase down what Google changed to cause multi-page forms not to work.
The logging functionality I have implemented will only work with forms defined using the new Custom Post Type (CPT) as the log data is stored as Post Meta data attached to the CPT for the form. In my current build I am working with all submissions are logged however there will be a setting to turn it on and off (default will be off) when I make a beta release available (hopefully today).
Access to the log is via a sub-menu selection from the Google Forms menu.
The log itself is implemented using the standard WordPress List Table class which provides a standard look and feel which WordPress users will recognize.
Log entries can be deleted (in bulk or individually but right now that is the only operation. Is there some other operation that would make sense? Export might make sense but I’ll defer on that for now.
I have posted wpGForm v0.46-beta-12 this morning. This update removes some debug code, updates the ReadMe file to reflect usage of the Custom Post Type and new wpgform shortcode, and adds the URL (permalink) of the page from which the form was submitted to the confirmation email (when used).
Now that the issues with the new version of Google Forms appear to be worked out, I am close to releasing this update. All I have left to do is to update my Help and Support Form to support the new usage model (CPT) and I think I am ready.
Things are finally settling down and I am able to spend some time on my WordPress plugins. I updated Email-Users this week and am now focusing on WordPress Google Form.
Shortly before I went out on vacation I learned from one of the people who has been testing beta releases that the CAPTCHA functionality was no longer working. I took a quick look at it and sure enough, somewhere between Beta 5 and Beta 10 I broke something and the CAPTCHA was not working but oddly enough, it was only broken on some browsers (e.g. Chrome) but worked on others (e.g. Firefox). These sort of bugs are a pain to chase down and with work being very busy and my family and I getting ready to go on a week long trip to Ireland, I decided to wait until I came back to figure out what was wrong.
It turns out I had introduced a very subtle syntax error in the jQuery script which defines which form fields are validated. I am still surprised it works in Firefox but not in Chrome. Regardless, it is fixed in Beta 11.
This bug affected me quite a bit as I have the beta version running on my site for Help and Support Requests and I had a slew of spam responses while I was out on vacation. Hopefully in my clean up I didn’t delete any real requests!
There are a lot of new features in v0.46, please refer to this post from about a month ago which shows how to request an email address from a user as part of the submission. This post explains how the new Google Form Custom Post Type (CPT) works.
I have inadvertently introduced a bug in the latest beta release of WordPress Google Form. The jQuery which handles the CAPTCHA is not running so a form can be submitted without validation. I hope to have this fixed and a new beta release available in the next few days.
The user had a test server I was allowed to access and I was able to narrow the problem down to a call to preg_match_all(), a standard PHP function.
The plugin settings page scrapes some content from the WordPress plugin repository and puts it on a tab within the Plugin Settings Page. The call to preg_match_all() involved a fairly complex regular expression to extract just the content I wanted.
It turns out there is an undocumented WordPress Plugin API which makes extracting this same date extremely simple. This beta release incorporates the API and eliminates the call to preg_match_all(). The solution is much cleaner, wish I would have known about this sooner!
Download the beta release and please let me know if you run into any issues.
It is no longer necessary to use this work-around, the WordPress Google Forms plugin now supports the new version of Google Forms. This post remains here are part of the development history of the plugin.
Thanks to a tip form Kevin Dillon, a work-around to the problem with new Google Forms has been identified! Legacy Google Forms are still available IF you start creating the form by opening a SpreadSheet first. Once the spreadsheet is open, select “Create a legacy Form” from the “Tools” menu. The form editor and published URL will be the same as those that had worked prior to the Google Forms update.
I have spent some time comparing low level WP_Http results against wget results and have come to the conclusion that Google Cookies aren’t being passed through the series of redirect which happens when viewing a Google Form with the new URL scheme.
Unfortunately I am not sure what to do about it yet. The usually very helpful WordPress Hackers mailing list is surprising quiet right now. I am trying to figure out if I can “remember” cookies and pass them along each time a redirect happens. I am reasonably confident that is what is needed however making it happen within the WordPress context is another story!
Last week Google introduced a significant update to Google Forms. In addition to a very different UI, the format of the public URL has changed AND more importantly, it has broken my WordPress Google Form plugin.
The change only seems to affect forms created from scratch using the new version of Google Forms. My plugin is dependent on the WordPress HTTP API to retrieve the form from Google and with the new URL format, the API is returning an error. I am trying to figure out what Google doesn’t like.
What is odd is I am able to successfully retrieve the form using the wget utility (a Unix command line tool for retrieving remote content) however wp_remote_get() doesn’t work.
I wish had some better news to report but right now I am stumped as to why this isn’t working.
If anyone has any ideas, I have posted some of the low level debug stuff on PastBin.
I’ve had a couple questions about the next version of WordPress Google Form. I have had a beta version of the next release of WordPress Google Form available for a number of weeks. So what is holding up the release? This is a pretty busy time of year for me at work (my real job) and combined with the holidays, I just haven’t had a lot of time to work on it.
This next update really changes how I recommend using the plugin and I want to make sure my Help and Support form can support it and right now it doesn’t. So until I can find a few minutes to update the Help and Support form, I am going to hold off on the release.