WordPress Google Form v0.56-beta-3 available

This evening I released beta-3 of WordPress Google Form.  This release addresses a requested feature to have “pre-populated fields which disappear when clicked“.

My solution to this request was to implement the placeholder attribute for the input tag.  This is also much easier than expecting users to decipher the complex URL requirements to pass default values to a form.  The difference between a placeholder and a default value is the placeholder value cannot be submitted.  In the case of wanting to have something like “email address”, which isn’t a valid email address, in the form field as a “placeholder”, using the placeholder attribute is a better solution.  At least I think so.

GForm_SS_60

Placeholder values are defined when the form is added as a Custom Post Type.

GForm_SS_61

Like the custom validation rules, to use placeholders you will need to know the name attribute for the field you are defining a placeholder for.  Refer to this post I wrote on Advanced Validation to learn how to identify the field name.

Google Forms Beta (8433 downloads )

Advanced Validation with WordPress Google Form

One of the most common requests I receive is the desire to validate fields on a Google Form. Google provides some basic validation (required or not) but there really isn’t a way to ensure that if you request an email address that the user actually provides a valid one. Similarly, there is a need for URLs, numbers, and other specific fields.

I’ve been using the jQuery Validate plugin (which looks to have a new  home) for a while now to validate required fields and in some cases, email addresses, and most recently, CAPTCHA support.

A number of people have asked me about extending the validation to include any field.  I have been reluctant to do this for several reasons:

  1. The jQuery Validate plugin needs to know which fields (by name or id) it is going to validate.  There isn’t an easy way to pull these out of the Google Form HTML.  It could be done on a single page form but because Google supports multi-page forms, they only way to find the information we need is to visit every page of the form.  This isn’t easy to do programatically.
  2. The rules needed to be written in jQuery syntax.  While the syntax isn’t difficult, if I allow entry of Javascript the potential for syntax errors (which would break the plugin) is very high.

For these reasons I’ve kept this on the back burner for a while.  However, a couple recent requests got me thinking about it again and it would be useful for a project I am doing for my daughter’s soccer team.  So I decided to dig into it.

I don’t think it is possible to make it completely foolproof however I did want to make it as simple as possible.  I decided to add a new Meta Box to the Custom Post Type editing screen which “helps” the user define new rules.

The key to making rules which accomplish something is getting the name attribute for the form entry element that needs to be validated.  There really isn’t a good way to do this other than to look at the HTML source.  I like FireBug with Firefox but both Chrome and IE have the ability to easily inspect an element.

GForm_SS_48Now that I know my input element’s name (entry.409811816) I can set up my new rule.

If you have been using WordPress Google Form the first thing  you’ll notice is the Form Editing screen has changed quite a bit.  The form was getting very long and cluttered so I have moved some of the lesser used options to a new Meta Box on the right hand side leaving just the critical or frequently used options on the primary Meta Box.

There is a new Meta Box just for Validation.  This Meta Box lets you add a series of fields where you can enter the name, the type of check to perform, and if needed, a check value.

GForm_SS_49Once the validation fields are set up, you can see the effect as you fill out a form.

GForm_SS_50 GForm_SS_51I am going to clean up a few things and make a beta release available for people to test with.  I think this functionality is pretty cool and it was a bit of a challenge to (a) get it working and (b) find what I think is a viable usage model.  As always, feedback is welcome.

 

 

 

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!

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.

Work-Around for Google Forms problem

It is no longer necessary to use this work-around, the WordPress Google Forms plugin now supports the new version of Google Forms.  This post remains here are part of the development history of the plugin.

Thanks to a tip form Kevin Dillon, a work-around to the problem with new Google Forms has been identified!  Legacy Google Forms are still available IF you start creating the form by opening a SpreadSheet first.  Once the spreadsheet is open, select “Create a legacy Form” from the “Tools” menu.  The form editor and published URL will be the same as those that had worked prior to the Google Forms update.

wpGForm_SS-002wpGForm_SS-003

Huh? How’d I miss WordCamp Raleigh?

I was perusing some WordPress feeds I follow this morning and was reading an article about recent debate on where Custom Post Types should live (plugin or theme – for the record, I am on the side that CPTs should reside in a plugin for the same reasons the article points out) on wpBeginner.com when I saw a mention that the debate originated at WordCamp Raleigh.

A WordCamp here in Raleigh?  How did I miss that?  Unlike many weekends where I am out an about with soccer, basketball, lacrosse or the like, I was around this weekend.  I couldn’t have gone to the whole thing but the venue for WordCamp Raleigh is maybe 15 minutes from my house.

Bummer – I really would have liked to have attended a couple of the sessions, in particular Using AJAX in your Plugins, Using Git with WordPress and a couple of others.

Maybe next year …

What to do when WordPress Google Form doesn’t work

So you’ve designed a Google Form and you’re happy with the layout of it.  Now you’re ready to integrate it with your WordPress site and you’ve decided to use the WordPress Google Form plugin.  Awesome.  Looks like it will do exactly what you want:  Easily create custom forms and gather data in a Google Docs spreadsheet for easy collection and dissemination of data.

So you install WordPress Google Form and get your shortcode set up and you visit your page to see the result.  In most cases, as long as the short code is properly set up, WordPress Google Forms works as advertised.  98% of the support requests I receive are for help with styling the form using CSS to make it match the host site better.

However, from time to time a user runs into an issue where WordPress Google Form simply doesn’t work.  This usually manifests itself in one of two ways:

  1. The form is never displayed and instead an error message that indicates the form couldn’t be retrieved and try reloading the page.
  2. The form displays properly but doesn’t submit correctly and the form results are never posted to the Google Docs spreadsheet.

Case #1 usually indicates one of two things:

  1. Most frequently the short code isn’t properly formatted.  This takes on all sort of possible problems, the most common one is when the WordPress Visual Editor converts the the URL to the form into a hyperlink.  There are other errors, such as the wrong quote character around attribute values but the hyperlink problem is by far the most common occurrence.
  2. Your web hosting environment doesn’t support the WordPress HTTP API.  This isn’t too common but it does come up from time to time.  It is very common on “free” hosting service packages.  Frequently these plans have fopen() and other remote transports disabled.  The only solution here is to move to a hosting plan which supports the WordPress HTTP API.
  3. A firewall prevents access to Google for remote requests.  I’ve only run into this once but it happened and it was very difficult to find.  In the end, I didn’t find it, the user did but that was after we had done a bunch of debugging to figure out what was going on.

Case #2 usually indicates a problem with Apache’s ModSecurity.

I’ve run into this a couple of times and made some pretty significant changes to the plugin to account for ModSecurity but there is still a chance it can kick in IF the user is being asked for a URL or a similar value which ModSecurity doesn’t like.  Right now there isn’t much that can be done when this happens except to not request URL values or to instruct the user to strip off the “http://” (or other) prefix.

In addition to the Debugging aid I’ve added to the plugin, I recently found the Core Control plugin.  Core Control is a very useful plugin for chasing down the sort of problems I’ve encountered with WordPress Google Form.  It can show which transports your server supports for the WordPress HTTP API and even has the ability to disable some of them to chase problems down.

If you run into problems, you can always use my Help and Support Form but also give Core Control a shot to see if it can help identify where the problem might be.

Suppressing White Space

One of the more common questions I receive is with respect to extra white space on a Google Form. Sometimes the rendering of the form within WordPress is significantly different than it appears within the Google Docs context and people want to know why and more importantly, how to fix it.

Fortunately Google Forms have lots of CSS classes so in all of the cases I’ve seen so far, I’ve been able to help the person solve their white space problem by adding CSS definitions to their custom wpGForm CSS settings to achieve the result they wanted.

The two most common problems I’ve seen so far are extra margin and/or padding on paragraph <P> element and/or <BR> element.  Another situation which I ran into recently involved a theme adding a <BR> element after every <P> element.  This was an unusual situation but I suspect not all that uncommon.  How would this happen?  A theme can define something called the_content filter which will modify the content of a page or post before it is rendered and in this particular case, the filter appended  a <BR> element at the end of every P element!

Fixing White Space Problems

So how do you fix these problems?  Extra padding or margin for the <P> and <BR> elements can be tweaked using the following CSS:

div.ss-form-container p { margin: 0px; }
div.ss-form-container br { margin: 0px; }
div.ss-form-container p { padding: 0px; }
div.ss-form-container br { padding: 0px; }

You may not need all four directives, in fact, in most cases you won’t but it might take a combination of the four to achieve the desired results.

Suppressing Extra <BR> Elements

What do you do if you encounter a situation like described above where the theme is adding extra <BR> elements or you simply don’t want them?  Again, CSS can be used to solve the problem.

div.ss-form-container br { display: none; }

This CSS will essentially prevent the browser from rendering the <BR> elements within the form.  They will still appear in the source HTML but they have no effect because they are not displayed.

I recommend using FireBug to help chase down CSS issues.  It is what I use when looking into problems people have asked me to look at.

Highlighting Missing Fields on a Google Form

A user of my WordPress Google Form plugin asked how to highlight the required fields on a form but only after submitting for the form without providing all of the necessary fields.  Essentially, how show an error more clearly, much like Google does with their forms when run standalone.

Here is a form that has required fields before it has been submitted:
Form with required fields before submission
Here is a form that has required fields after it has been submitted:
Form with required fields after submission
Note that the form label is now red instead of the original black. To have the field text appear in red only after submitting the form without providing the required field, I used this CSS:
div.errorbox-bad div.ss-item-required label {
color: red;
}

If you use the prefix attribute in your short code you’ll need to adjust the class names accordingly. There are quite a few CSS tricks you can do to highlight errors and for experimenting, I recommend FireBug to tweak CSS without having to reload the page each time.