While looking into a Support request I discovered a bug in the generation of the jQuery validation script which caused a syntax error. This syntax error could potentially cause problems with redirection upon form submission.
While fixing the above bug I also added support for embedded images which had been requested recently. When you design your form Google now allows the insertion of images and now Google Forms will display them properly.
You can find this update on your Dashboard or in the WordPress plugin repository.
Another minor update to Google Forms to fix a bug reported late last week. It turns out I left out a named array parameter in a call to wp_update_post(). What is interesting is this problem manifests itself differently on various installations. I never saw the error reported however when the offending line was pointed out, it was obvious to me what was wrong.
This morning I released a very minor update to Google Forms. In the process of verifying that I fixed the form submission log I found a typo in one of the internationalization strings and some debug code which was still enabled. Neither issue would cause the plugin to fail but I went ahead and fixed both and released an update.
This evening I released v0.66 of Google Forms. This version fixes two major issues:
The conflict with WordPress SEO has been resolved. The implemented solution will likely be replaced with something which runs less frequently. However, the solution implemented in v0.66 should make sites running both Google Forms and WordPress SEO a little happier.
Due to a bug, all form submissions have been logged regardless of the plugin setting.
You can find the update on the WordPress plugin repository or on your Dashboard.
I have been working on resolving a plugin conflict between WordPress SEO and Google Forms. Based on some help from the WordPress SEO plugin author I have made some small changes to Google Forms which I believe will alleviate the conflict.
I am looking for people who’ve been dealing with this problem to test this out, if you have a few minutes, please download this beta and give it a run through.
This morning I released v0.65 of Google Forms, a long overdue update. I have been sitting on this release for a while because of one outstanding issue I was aware of which I simply haven’t had time to chase down. The ability to email the end user upon form submission broke at some point, I am not exactly sure when but it has been reported a few times recently. It turns out, it only worked if email to the admin was also enabled.
Here are the highlights from the Change Log:
Implemented “save_post” for custom post type eliminating general purpose “save_post” (only option prior to WordPress 3.7) action which could potentially, if not handled correctly by another plugin, corrupt post data.
Formally deprecated the gform shortcode by updating README file.
Added flush of rewrite rules upon plugin activation and deactivation.
Implemented protocol relative URLs for loading jQuery script from Microsoft CDN to avoid mixed-content warnings when serving over https.
Fixed layout of CAPTCHA options on settings page.
Fixed bug with preset values as part of the URL which contain spaces.
Fixed bug sending End User email upon form submission.
Refactored construction of email headers based on experience with Email Users plugin.
Yesterday on my flight to Phoenix I implemented a feature which was recently requested to use the To field for the recipient address when the BCC limit is set to 1. There is a new choice in the BCC Limit option on the Settings page:
If you’d like to test this new feature, download this beta build and report any issues you encounter. It will work with both Post/Page notifications as well as group emails. The only limitation is when used, the user’s email address will be placed in the To header without their display name.
Google Forms has supported additional URL parameters for a while as a mechanism to preset form values. The problem turned out to be that parameters which contained spaces weren’t being handled properly which resulted in a bad URL. The bad URL was then used to retrieve the Google Form which failed and resulted in the form not displaying.
This build properly handles spaces in URL parameters and Google ignores, as expected, any parameters it doesn’t know what to do with. So in the case reported on the Support Forum, the extra parameters added by MailChimp will simply be ignored.
This afternoon I posted beta-1 of Email Users v4.6.6. This build addresses an issue reported on the Email Users support forum. The user reporting the issue was running into a feature that was actually designed into Email Users – the ability to email a user regardless of their Mass Email and Notification settings.
Based on the user’s use use case, I can understand the desire to prevent certain types of users from appearing in the User Recipient List. So I have added a new option to the settings page which will prevent users who do not have a role on the web site from appearing in the Recipient List.
Please report any issues with this new functionality ASAP and I will try to address them quickly.
I received a patch over the weekend from a Google Forms user which I have incorporated into beta-2 of v0.65. The patch changes how Google Forms loads the jQuery Validation plugin from the Microsoft CDN. The plugin is now loaded using a protocol relative URL. This change will eliminate the mixed content message which appears on sites using HTTPS.
There are a couple other minor fixes in this build as well, the most notable a flush of re-write rules upon plugin activation or de-activation in hopes that it will eliminate one of the most common questions I receive (why doesn’t my URL work when I click the View Form button?).