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.

Constantly Amazed by jQuery

I am constantly amazed by what one can do with jQuery.  If it were not for jQuery, I don’t think I would have continued working on WordPress Google Forms.  I’ve used jQuery to adapt check box parameters so they will pass from PHP (used by WordPress) to Python (used by Google for form process).  I’ve used jQuery to implement CAPTCHA.  I’ve used jQuery to implement multiple columns.  And now I am using jQuery to work-around the language issues which have recently become a problem.

Recently Google changed the structure of Google Forms.  The new version no longer supports the hl=XX (where XX is a language parameter such as en or fr) parameter.  For most instances this isn’t a problem.

However, there are some cases where Google thinks the server hosting WordPress (and hence WordPress Google Forms) is located in a certain part of the globe and therefore should receive Google Forms with some of the boiler plate text in the native language suitable for the location.  Awesome.  Google thinks I need German buttons and text.  I don’t speak German nor do any of my users however the server is physically located in Germany. Now what?

Over the past couple of days I been implementing jQuery that finds the default text which Google is serving in  a native language and allowing WordPress Google Forms to override it.  I am doing this with jQuery.  Fortunately Google adds numerous CSS classes to their forms so most of the replacements can be accomplished in a single line of jQuery.  However, there is one situation where it isn’t so simple.

If you employ a multiple choice question, Google provides an option to add an “Other” choice where the user can type in another answer.  Again, very nice of them.  However the “Other” text is one of those that Google serves up in a localized language and more importantly, it isn’t wrapped in a SPAN or a DIV with a CSS class that makes it easy to select.

Here is one of the questions on one of my development forms.  You can see I’ve already overridden the “hint” (which is also new):

GForm_SS_42

Here is the same question with the “Other” text overridden:

GForm_SS_43

So how do we select just the “Other” text but only when using a multiple select widget which employs an Other choice? jQuery and Javascript to the rescue:

$("div.ss-radio label:last+span.ss-q-other-container").prev().contents().filter(function() {
        return this.nodeType == Node.TEXT_NODE;
    })[0].nodeValue = "<<<<Other:";

This snippet of jQuery (which I got some help on from this thread on StackOverflow) combined with Javascript selects the one case there is and replaces it with my override.  Pretty slick eh?

Look for another beta update today with more override options.

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

This afternoon I uploaded WordPress Google Form v0.46-beta-15 which addresses a CAPTCHA problem.  CAPTCHA requires Validation and unless Validation was specifically enabled for the form, the Validation code wasn’t loaded and hence CAPTCHA wasn’t running.

I also added some new default CSS to account for some of the CSS changes Google has made lately.  Google has actually made quite a few CSS changes so I need to make sure it is all covered.

This morning Google also made some changes to Check Boxes and Radio Buttons adding more text which is subject to the language problem.  The quick fix is to hide the new text using Custom CSS:

div.ss-printable-hint { display: none; }

Download the latest beta and please provide feedback on any issues you run into.

Google Forms Beta (1968 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.

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.

WordPress Google Form v0.46 beta 11 available

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.

Google Forms Beta (1968 downloads)

WordPress Google Form v0.46 beta 9 available

I’ve updated the beta version of WordPress Google Form v0.46 this morning to beta-9. This beta update adds a significant new feature and one that has been requested a number of times: The ability to require an email address from the person filling out the form is now possible through a setting on the Google Form custom post type (this is not available through the old gform short code).

I would encourage migrating to the new short code and defining forms with the Google Forms Custom Post Type UI as that is where I am adding new functionality.  The way I added the User Email option should also allow me to allow form specific validation rules (e.g. URL required).

Download the beta release and please let me know if you run into any issues.

Google Forms Beta (1968 downloads)

WordPress Google Form v0.46 beta 5 available

I’ve updated the beta version of WordPress Google Form v0.46 to beta-5 and made it available for download from this site. This beta update addresses an issue where content is floating to the wrong location. The addition of column support using jQuery Columnizer plugin injects several DIVs to wrap the column content and the DIVs which contain the columns are floated either left (default) or right. I have added some additional jQuery code to clear the floats at the end of the Google Form.

Download the beta release and please let me know if you run into any issues.

Google Forms Beta (1968 downloads)

wpGForm Custom Post Type Preview

As I noted a couple days ago, I have started a “renovation” of sorts to my WordPress Google Forms plugin.  I have defined a Custom Post Type which makes it much easier to set up a form.  It is no longer necessary to worry about the syntax of a long complicated short code!  Here are a couple images of what the Dashboard UI looks like.

Adding a form to a post or page is as simple as adding the

Unable to process Google Form short code.
short code where N maps to the form’s post id.  The short code syntax for each Google Form appears in the list of forms.

The Google Form Edit Screen has fields which map directly to all of the short code attributes that were defined in the original short code.

There is no change of operation on the front end – the form should continue to operate as it has previously.  If you’re interested in testing this new version, I hope to have a beta available fairly soon which also has some other new features.

Moving to a Custom Post Type may allow for some more robust field validation using the jQuery Validation plugin!  Stay tuned for  more details on that as I don’t think it will be in the first release of Custom Post Types.