WordPress Google Form v0.55 released

Yesterday WordPress 3.6 was released.  The bundled version of jQuery was updated to 1.10 which broke the jQuery Columnizer plugin I use to split a form into columns.  The result was jQuery would go into an infinite loop and eventually you would have to kill the page.

Fortunately someone had already encountered this problem and provided a patch to the jQuery plugin.  I have incorporated the patch and released v0.55.  If you’re running WordPress 3.6, this is a critical release.  Older versions should continue to run correctly.

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

WordPress Google Form v0.54 released

This morning I released v0.54 of WordPress Google Form.  It has been a while since I’ve had any bug reports for the current version or the beta version.  Things appear pretty stable.

  • Added internationalization support for jQuery Validation messages.
  • New language support files.
  • New jQuery Validation based custom validation option.
  • Fixed problem with escaped characters ending up in Google spreadsheet.
  • Moved transport control out of debug module and into core code so it can be a permanent setting for some server environments.
  • Fixed PHP warning messages which happen with Logging Enabled when some of the server variables don’t exist.
  • Fixed bug with Form Submission Log setting stickiness.
  • Added an optional CAPTCHA message which will appear below the CAPTCHA input when set.

WordPress Google Form v0.54-beta-6 now available

I have a posted a new beta version of WordPress Google Form.  This version (v.054-beta-6) fixes a problem reported today which happens when Logging is enabled on certain servers.  This update will now test for the variables it wants to track before trying to use them.

This update also includes an enhancement with respect to HTTP API Transports.  Previously the plugin allowed control of the various transport options in debug mode.  Recently I found a case where it made sense to disable one of the transports on a permanent basis so I have pulled that functionality out of the debug module and moved it into the plugin core.

Google Forms Beta (428 downloads)

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.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 (428 downloads)

Why are my buttons in Chinese?

Periodically I get a question from someone using WordPress Google Form asking why their buttons (and some other text) is in Chinese (or some other language but Chinese is the most common)?

If you haven’t run into this problem, consider yourself lucky!  The problem manifests itself similar to the images below.

GForm_SS_35 GForm_SS_36

As near as I can tell, this problem happens when the Web server that is running WordPress Google Form is geographically located in a part of the world where Google thinks it should serve up a particular language.

So how do you fix it?  In the previous version of Google Forms, the solution was simple:  Add &hl=en to your form URL and Google would deliver the content in the specificed language (in the case English) – refer to to this post for more details.  Unfortunately the new version of Google Forms doesn’t support this language parameter so I have been at a loss to help people who find themselves in this situation.

For several days I have been trying to find a solution.  Adding cookies to the wp_remote_get() request, .htaccess entries, PHP locale settings, etc.  Nothing made a difference.

While at the gym this morning it dawned on me that there isn’t any reason why I couldn’t “fix” the problem by processing the HTML that Google generates with jQuery.  So that is what I have done.

GForm_SS_37

 

I have renamed the Debug tab to Advanced Options and added the ability to define the text that will appear on the Submit, Back, and Continue buttons as well as the text which indicates fields are Required.

WordPress Google Form v0.46-beta-13 available

This afternoon I uploaded WordPress Google Form v0.46-beta-13.  Yes, this is the 13th beta release of WordPress Google Form v0.46.  Why so many?  Mostly because made a significant change to Google Forms at about the same time I was introducing a major change to WordPress Google Forms.

This release adds a new feature – the ability to log form submissions.  This is something I’ve wanted to do for a while.  The next update will include some settings to control the log (on, off, entries per page, etc.)  but in this beta release, it is on and shows 10 entries per page.  There is a known bug in the pagination of the log file.  The URL to move between pages is wrong and I haven’t been able to determine how to add the CPT and page information which the URL requires to be valid.

Most importantly, this beta release addresses a major bug with multi-page Google Forms AND Google Forms with checkboxes that are created with the new version of Google Forms.  This functionality needs testing so please put it through its paces.

Google Forms Beta (428 downloads)

New Google Forms break multi-page support

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.

Logging Google Form Submissions

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.

GForm_SS_33The log itself is implemented using the standard WordPress List Table class which provides a standard look and feel which WordPress users will recognize.

GForm_SS_34

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.