WordPress Google Form v0.50 now available

WordPress v0.50 is now available.  This update fixes a jQuery syntax error which occurred when validation was but user email and CAPTCHA were off.  Along with the bug fix I also added CSS to hide the “Never submit passwords through Google Forms.” message that Google has added to forms.

You can find the update on your WordPress Dashboard or in the WordPress plugin repository.

Debugging a weird one

Yesterday I was contacted by a WordPress Google Forms user who was getting a permission denied problem when submitting his form.  After trying a number of obvious things (like disabling all other plugins), I asked him to try switching to one of the default WordPress themes.  He switched the site over to use TwentyTwelve and the problem went away.  Yeah!  I was worried that we might be dealing with another ModSecurity problem.

So we narrowed the problem down to something in his theme but what would generate a 403 error?  The user was gracious enough to let me have access to his site.  By enabling Debug, I was able to see a dump of the header information.  The header information showed a redirect was being requested (makes sense due to 403).

Using Firebug I could see that the POST variables looked correct.  Oops, maybe not.  Everything looked ok except a hidden variable that Google uses in forms to pass information between the pages of multi-page forms.  Even single page forms have this hidden variable.  On the initial load of the form, this variable should be empty (a null string) but it wasn’t.  How could that happen?

Looking at the HTML page source for the form, I could see there was quite a bit of odd stuff in the form code.  It doesn’t come from Google, where does it come from?  Because form submission worked with TwentyTwelve but didn’t work with the user’s theme, I suspected there was a filter mucking with the HTML.

Sure enough, digging through the theme’s functions.php file I found a custom filter that did several things, one of which was make a call to wptexturize().  Well that would certainly explain the manipulated HTML.

The next step was to comment out the calls to the filter to verify that was indeed the problem.  As expected, the form submitted without any issues.  At that point I wasn’t sure what to tell the user.  We could have left the filters commented out but they are part of the theme and there for a reason.  I decided to look at the filter a little closer.  It turns out, the theme defines a short code, actually, it doesn’t define one, the filter looks for one, called [raw][/raw] and if it finds it, leaves the content between the short code tags untouched.

Well this will work!  So I created a test page and placed the wpgform short code between [raw][/raw] and sure enough, the form submitted properly.

While I don’t like what the theme is doing, at least there was a work-around for it.  Unfortunately there is no way (yet) to accomplish the same thing with the Form URL.

This whole process took a couple of hours – far more than I am typically able to spend helping people but I was genuinely curious what was going on.  I am glad we got the user up and running.

I am trying to think of a good way for people to define forms which can handle such a situation.  I can define a hook but that means people need to write some code to use it or I could define more options for the plugin that allow the generated HTML to be wrapped in some prefix and suffix text (plain or HTML).  I am not sure what to do so will continue to think about it for a day or two.

WordPress Google Form v0.49 released

A pretty serious issue was reported in the Support Forum this afternoon.  I have found and fixed the bug and pushed out an update.  While I was at it, I also adjusted the default CSS so the Help Text for form fields is visible. I had inadvertently hidden it with CSS in the v0.46 release.

The update will appear on your WordPress Dashboard or you can find it in the WordPress plugin repository.

WordPress Google Form v.0.47 released

This morning I pushed out v0.47 of WordPress Google Form.  This update fixes a problem in which various combinations of options would result in jQuery syntax errors which in turn resulted in Javascript errors.  In some cases, the plugin would not properly complete, particularly when using checkboxes and/or custom confirmation pages.

You will see the update on your WordPress Dashboard or you can find it in the WordPress plugin repository.

WordPress Google Form v0.46 is finally out!

After 19 beta releases, the first one being back on November 14, 2012, this afternoon I released v0.46 of WordPress Google Form.  This update represents a significant change in how the plugin works.  The plugin now defines a Custom Post Type for defining forms which is much easier to use than the old shortcode.  The shortcode was getting very complicated with all of the options.

The Custom Post Type functionality is supported by a new shortcode, wpgform, which is much easier to work with as it only has one argument, the Post Id of the form.  The original gform shortcode will continue to work however it will not received new features (e.g. columns) and at sometime in the future, I will likely deprecate it.

During the development process of v0.46, Google made a significant change to Google Forms.  The change required re-work of a number of features, support for multi-page forms being the most important and hardest to figure out.  Things changed on Google’s side several times as they rolled out the update to Google Forms.  The most recent change restored the ability to control the language of certain parts of the form immediately after I had spent several days working out a jQuery solution to allow text replacement on certain form elements.

There has been quite a bit of testing of this update over the past few months and I want to thank the people who tested the early releases and reported problems.  In particular I want to thank several people who trusted me with access to their server in order to chase down and debug some very odd problems.  In the end , I think I was able to resolve all of them.

The only known issue at this point is with respect to IE7 support.  I cannot get the validation support to work with IE7 which means the CAPTCHA doesn’t work properly either.  If someone can figure it out I am happy to incorporate a fix but I have exhausted by ability to chase down an odd problem with an ancient browser.

The number of new features and fixes is pretty long, I recommend reading the v0.46 release notes here.

You can find the update in the WordPress plugin repository or as an update on your WordPress Dashboard.  If you have any problems, I have retooled my Help and Support form to mimic the fields on the Custom Post Type screen.  Don’t hesitate to use it if you run into something which isn’t working.

WordPress Google Form v0.46-beta-18 now available

I am getting close to a formal release.  This beta update adds support for using the public facing Custom Post Type posts directly.  This means when you define a Google Form using the Custom Post Type interface and publish it, the permalink can be used to view the form.  It can also be used as a menu item or link.

It is no longer necessary to add a short code to a separate page or post although it will still work.  I am strongly encouraging users to move away from the original gform shortcode with a bazillion options to using the Custom Post Type.  Going forward, new features will only be added to the Custom Post Type (e.g. columns only work with the Custom Post Type).

GForm_SS_47GForm_SS_46

Google Forms Beta (928 downloads)

WordPress Google Form v0.46-beta-17 is now available

I have just uploaded WordPress Google Form v0.46-beta-17 which addresses one bug and adds new capability to the CAPTCHA functionality.

  • CAPCTHA can now have 2 or 3 terms
  • CAPTCHA now supports operators for addition (+), subtraction (-), and multiplication (*)

GForm_SS_44 GForm_SS_45

I finally found a solution to passing the query arguments correctly so the page navigation for the Form Submission Log now works properly.

At this point I think I am close to done with this release.  Scope creep can be a killer and it has been a long time since I’ve formally released an update.  With the number of questions I am getting about new Google Forms and all of the fixes being in this beta, it is time to get it out!

The next question to resolve is do I bump the version number to 1.0 with all of the changes I’ve made or continue as it is and release v0.46 – thoughts?

Google Forms Beta (928 downloads)

New Google Forms now support the language parameter!

For several weeks I have been trying to figure out a solution how to handle language issues with new Google Forms.  In the old version, a URL parameter could be specified (see this page).  However, this didn’t work with the new version of Google Forms.

Until today.  Thanks to a posting on the WordPress Support Forum, I was alerted to the fact that the URL parameter is indeed working again.  This is great news as dealing with odd language issues is one of the more common support requests I receive.

In the new version of Google Forms, simply append ?hl=en (or ?hl=fr for French, etc.) to the end of the URL of the live form.  Wish they would have done this several weeks ago, would have saved me quite a bit of time!

WordPress Google Form v0.46-beta-16 is available

I have just uploaded WordPress Google Form v0.46-beta-16 which addresses one bug and adds the ability to oveeride the default Google text in several more areas:

  • Radio Button hint
  • Check Boxes hint
  • “Other” option when allowed as a Radio Button option

The bug fixed had to do with saving the Options tab losing the Override setting on the Advanced Options tab.  It only happened if the Options tab was saved after the Advanced Options but now that it is fixed, save order is no longer an issue.

I also added some more default CSS to account for some of the CSS changes Google has made lately.

Google Forms Beta (928 downloads)