I’ve had my Help and Support form for my WordPress Google Form plugin online since April and it has greatly improved my ability to help people use my plugin. I get all of the information at one time where as before it took several passes via email to get all of the data I typically need to resolve an issue.
Up until about two weeks ago, I never got any spam via the form but lately I’ve been receiving 2-3 form submissions per day that contain nothing but gibberish. So it got me thinking about how to implement a Captcha solution. A Captcha solution has been requested several times and I’ve never looked at it seriously because (a) Google doesn’t support it and (b) it wasn’t something I thought was terribly important. I am rethinking my position how important it is! 😉
The fact that Google doesn’t support a Captcha solution is the biggest hurdle. The challenge is to add the necessary code to the HTML generated by Google, recognize and process the Captcha, and it is passes, remove the Captcha input prior to submitting the form values to Google for processing. This becomes a more complicated issue on a multi-page form: Does every page have a Captcha or only the last page with the Submit button?
I don’t have a solution yet but this is something I am noodling on as I have some spare cycles. The solution will almost certainly be jQuery based, I can’t think of a better way to do it and I am already using jQuery to process radio button inputs so they can be converted from PHP style inputs on the WordPress side to Python style inputs on the Google side.
This morning I released v0.39 of my WordPress Google Form plugin. This update addresses the corner case exposed when using WordPress Google Form with the Unite theme from Paralleus. To solve this incompatibility I’ve introduced a new short code attribute called unitethemehack which defaults to off. By turning it on, WordPress Google Form will modify the Google Form HTML to protect the Submit button(s) from being manipulated by the Unite theme.
After a couple weeks of sitting on a new release, I have pushed out v0.31. This release addresses the ModSecurity problem that I had noted in a post a few weeks ago. After chasing this problem down with the help of several users who were willing to work with debug code and/or give me access to their server, I was able to figure out what was going on.
The simple explanation is that the Apache ModSecurity module can be pretty restrictive and returns 403 errors when a form is submitted. WordPress then does it’s thing and concludes that the page should be displayed again. The net result is that form is never submitted and no feedback is provided to the user. From what I’ve seen, ModSecurity doesn’t like URLs passed as parameters which WordPress Google Form does for the Google Form – it needs it to submit the responses to the form.
With this update two things have changed:
If a 403 error is returned, the plugin will check for it and show a message if/when it happens.
The Google Form URL is passed as an encoded parameter so it doesn’t get flagged by ModSecurity.
These changes won’t address all instances when ModSecurity kicks in – if your form includes any input where a user can type a response AND they user submits a URL as a response, there is a pretty good change a 403 error will be issued by the server.
Hopefully this change will help some very odd use cases where users don’t understand why the plugin isn’t working for them. It has worked in four (4) additional situations that users have asked me to look at it plus the two original that I looked at.
Today I pushed out wpGForm v0.29. This version adds one new feature and addresses an unusual problem which prevents the custom confirmation page, either AJAX or redirection, from loading properly.
Based on several requests, I have added a new short code attribute, sendto=<email address>, which when used in conjunction with email=’on’, will send a form submission note to the specified email address instead of the blog administrator (who is still bcc’d for backup purposes).
I’ve received a couple of requests to have an email notification sent out when a form is submitted. Today I released v0.26 which supports a new attribute (email=’on|off’) on the gform shortcode. By default email notification is off but when set to on, an email to the blog administrator will receive an e-mail indicating a form was submitted. The email also contains the URL for the form, and date and time the form was submitted.
Email can be sent in either HTML or Plain Text formats, there is a new option on the settings page. By default email notifications are sent in HTML format.
Last night while I was at my daughter’s basketball practice I finished up modifying the Events functionality to account for the new events groups which will allow events to be bundled into logical groups. As I was testing everything and things seemed good to go, I realized that the Drag-and-Drop event re-ordering won’t work correctly.
The DnD re-ordering assumes there is only one set of events so as the events are rearranged they are renumbered from 1-N. This isn’t a show stopper but I will have to come up with a new solution. In the process of playing around with some ideas I have determined that the jQuery plugin I was using has been updated to support touch so I have folded that in and everything which was working still works.
I had hoped to get a new release out this week but that is unlikely to happen at this point. I am not going to release anything until I have the event reordering fixed unless I get a serious bug report in which case I’ll simply disable Drag-and-Drop reordering until I get it working again.
Yesterday 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.
This 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.
Yesterday I committed and tagged the v0.12 release of my WordPress Google Form plugin. It is available from the WordPress plugin repository. The main feature of this release is support for multi-page Google Forms. The changes made to support multi-page forms should also enable use of fields that have optional answers.
There is still some leftover code from the old validation process that I was reluctant to completely remove until I know for sure this new architecture is working in more use cases than I have to test with. There will likely be another update that is nothing more than a code clean up in a couple weeks unless someone reports a problem.
This morning I posted an updated wpGForm v0.11 beta release. This updated beta introduces two new shortcode attributes:
title=’on|off’ – Show (default) or remove the Google Form title. The title is often redundant with the WordPress post or page title, this attribute will allow you to remove the title from the HTML displayed within the WordPress context.
maph1h2=’on|off’ – Map H1 elements (usually just the title) on the Google Form to H2 elements. This allows you to retain the form title from the Google Form but map it’s H1 tags to H2 tags which prevents multiple H1 tags from appearing on the WordPress page (which I understand is an SEO no-no).
This build also includes default CSS definitions for div.ss-q-help classes. Why the help text appears adjacent to the question as opposed to on top of it is a question comes up pretty frequently. This CSS makes the output more consistent with how Google presents the form so I’ve decided it should be the default.
I’ve also started removing debug and obsolete code.