WordPress 3.3 and WordPress Google Form?

The answer is:  I don’t know yet.  WordPress 3.3 came out last night and I am just playing with it now.  One of the key features of WordPress 3.3 is the inclusion of the complete JQuery UI library.  This definitely affects wpGForm because I am loading one of the UI libraries that wasn’t previously included from Microsoft’s CDN.  That will no longer be necessary (yeah!).  I guess the question now is what to do about backward compatibility with older versions of WordPress.

Historically I’ve just put a stake in the ground and moved on but wpGForm is the first WordPress theme or plugin that I’ve done that has quite a few users so I’ll probably implement some sort of version detection and conditionally load the UI library from the CDN if running an older version of WordPress.  A little more work for me but probably the right answer.

WordPress Google Form bug fix

In the process of trying to solve the multipage Google Form problem, I found a bug with the “Confirmation” page.  When a custom confirmation page isn’t supplied, the plugin is supposed to use the default Google conformation page.  It currently isn’t, instead the page the form is on is rendered again.  This is incorrect behavior and I’ve fixed it in my development thread and it will appear in the next release.

Multipage Google Forms – no solution yet

Yesterday I had some time to look at supporting multipage Google Forms.  Unfortunately it doesn’t look like it will be possible because of the way multipage forms work.  As you work through a multipage form Google adds hidden values to each successive page to facilitate moving forward and back without losing any data.  Pretty standard stuff for a “wizard-like” form implementation.

The problem is the way the plugin is implemented, the HTML code for the form is extracted and then re-processed before being added to a page within WordPress.  What I’ve implemented works fine for a single page form, actually, in my opinion, it works pretty well.  However, detecting the page transitions and obtaining the hidden form fields either isn’t easy or isn’t possible.  Right now I am leaning toward the later because the hidden fields are generated based on the prior page (Continue or Back) form submission.

What I have successfully made work is to use the “embedded” version of a Google form within a WordPress page.  It works but aesthetically it looks awful.  What I am playing with right now is some jQuery to try and manipulate the embedded form to use the styling from the site instead of from Google.  We’ll see how it goes ….

CSS for the WordPress Google Form Submit button

I was recently asked how the Submit button could be styled when using a Google Form in conjunction with my WordPress Google Form plugin.  Fortunately this was an easy question to answer because I had done something similar for another site.  Now I suspect the person asking me didn’t want to make their submit button pink but the CSS selector should be the same – it is just a matter of adding the CSS directives to achieve the desired affect!  I used the following selector to style the Submit button:

div.ss-form-entry>input[type="submit"] {
    background-color: pink;
}

This little trick should help further integrate Google Forms with your WordPress site.

Update: Recently I was asked how to style only the Submit button – all other buttons (e.g. Back, Continue, etc.) and input fields should keep their default styles. Here is some CSS which will style only the Submit button:

div.ss-form-entry>input[type="submit"][name="submit"] {
    background-color: pink;
}

Read-Only Google Forms?

This morning I added a new feature to my WordPress Google Form plugin.  You can now set a form to be ‘read only’ using the readonly=’on’ attribute in the shortcode.  This option, when turned on, use a little snippet of jQuery to disable all of the form elements.

[gform form='<long_url_to_your_google_form>' readonly='on']

I suspect your immediate reaction to this is “why would I want my form to be read only?” and it is a logical reaction.  After all, the whole point of creating a form is to collect data right?  The purpose of some forms, in fact I’d bet it is the case for most forms, is to collect data for some period of time and after a certain point (e.g. 5:00 PM on October 31), there is no reason to collect data any longer.

Imagine a sign up sheet for working the snack bar at your local High School football game.  Once the game has happened, there is no value in letting people sign up any more.  The readonly option will allow you to retain the form as part of your WordPress web site while preventing the collection of any more data.

I need to do little more testing before I release an update but so far, it looks pretty good!

Note:  The more I think about this, I may want add an expire option after which the form will automatically become read only.

Hiding bullets on a Google Form

Because the multiple choice fields on a Google Form are rendered as an unordered list (with a UL tag), by default, the form will appear like this:

 

 

Add this CSS to either the theme or via the wpGForm custom CSS settings:

div.ss-form-entry>ul li {
    list-style-type: none;
}

After adding the above CSS it will appear like this:

Hopefully this will help you make your Google Forms look the way you want within WordPress!

7/4/2012 Update:

Based on a couple examples I’ve looked at for wpGForm users, I have updated the CSS to specifically select the <li> item and remove the bullet.  This should be much more reliable than applying it at the <ul> parent element.

 

 

 

 

 

Hiding a Google Form’s Title

Since a WordPress page or post will have a title, there is a good chance the Google Form’s title is redundant.  If hiding the title from the Google Form is desired, the easiest way to do it is with CSS.  The title on a Google Form is an H1 element  which is assigned the class ss-form-title.  To hide the title, we add the following CSS to either the theme’s CSS or to the CSS overrides available with the WordPress Google Form plugin’s setting menu.

h1.ss-form-title {
    display: none;
}

Using my Sample Form, here are the results of adding this CSS to the plugin settings.

Form before adding CSS

Adding CSS to wpGForm settings

 

 

Form After Adding CSS

WordPress Google Forms include quite a few CSS classes so using this technique, the appearance of the form can be customized quite a bit.

Support for multi-page Google Forms?

I received an email the other day about my WordPress Google Form plugin wondering whether or not it should work with multi-page Google Forms  It hadn’t even occurred to me to test it as none of the forms I had needed myself were multi-page forms but my gut reaction was I didn’t think it would work.

I took a look at a multi-page Google Form and have determined that the current (v0.10) version of the WordPress Google Form plugin (aka wpGForm) will not work with multi-page forms.  No real big surprise but I want it to be clear before someone else wastes their time trying to make it work.

From looking at the form code it may be possible to support multi-page forms in the future but it will require some additional jQuery scripting and more importantly, some time to dedicate to it.  I hope to look at this soon but I have a couple of WordPress theme projects that I need to get off my plate before I can go back to wpGForm.

WordPress Google Form v0.10 released

Yesterday I committed the final changes (and still missed a few typos – ugh) to the WordPress plugin repository.  The v0.10 release addresses the problems with required fields on a Google Form.  I’ve heard from several people who’ve told me this fixes the problems they were seeing but if you run into something, add a comment here and I’ll do my best to take a look at it.

Note:  I’ve also changes the beta download link to resolve to the WordPress download so the beta is no longer available.

WordPress Google Form beta update

This morning I fixed a bug which occurred when the default CSS was not enabled (which it isn’t by default).  When the default CSS was not enabled, the jQuery Validation plugin wasn’t loading and then the jQuery script that initialized the validation would fail.

If you downloaded the beta prior to 10:00 EDT on 10/7, you should download it again and re-install.

[download#7]