WordPress Google Form v0.31 released

After a couple weeks of sitting on a new release, I have pushed out v0.31. This release addresses the ModSecurity problem that I had noted in a post a few weeks ago.  After chasing this problem down with the help of several users who were willing to work with debug code and/or give me access to their server, I was able to figure out what was going on.

The simple explanation is that the Apache ModSecurity module can be pretty restrictive and returns 403 errors when a form is submitted.  WordPress then does it’s thing and concludes that the page should be displayed again.  The net result is that form is never submitted and no feedback is provided to the user.  From what I’ve seen, ModSecurity doesn’t like URLs passed as parameters which WordPress Google Form does for the Google Form – it needs it to submit the responses to the form.

With this update two things have changed:

  1. If a 403 error is returned, the plugin will check for it and show a message if/when it happens.
  2. The Google Form URL is passed as an encoded parameter so it doesn’t get flagged by ModSecurity.

These changes won’t address all instances when ModSecurity kicks in – if your form includes any input where a user can type a response AND they user submits a URL as a response, there is a pretty good change a 403 error will be issued by the server.

Hopefully this change will help some very odd use cases where users don’t understand why the plugin isn’t working for them.  It has worked in four  (4) additional situations that users have asked me to look at it plus the two original that I looked at.

You can find the update in the WordPress Plugin Repository.

wpGForm and Apache Sercurity

A while back I was contacted by a user who had deployed wpGForm on their site with a problem they wanted my help with.  In looking at it I was absolutely stumped as to why it wasn’t working.  Nothing appeared obvious – when the form was submitted, the form would be displayed again as if for the first time.  In the process of chasing down this problem I’ve added quite a bit of debug code but in the end, I found Firebug’s Net Panel incredibly useful.

In this particular case it was showing me that the form was being posted but a 403 Permission Denied response resulted.  Why?  The exact same URL worked to show the form, why wasn’t it working to process the form?  I ended up separating the rendering and processing part of the plugin thinking this was the problem (like it was on a site a couple of weeks ago) but it didn’t make any difference (although it was the right thing to do).  I was still getting 403 problems.

I was working closely with the site owner, they were nice enough to allow me to really dig into their site.  What did I find?  A bunch of plugin and theme minor issues that I chased thinking they were conflicting somehow to no avail.  I ended up opening a ticket with the hosting provider and once we clarrified the problem, they sent me so error log information:

[error] ModSecurity: Access denied with code 403 (phase 2).Match of "rx
://%{SERVER_NAME}/" against "MATCHED_VARS:gform-action" required.
[file "/usr/local/apache/conf/modsec/10_asl_rules.conf"]
[line "489"]
[id "340162"]
[rev "262"]
[msg "Atomicorp.com UNSUPPORTED DELAYED Rules: Remote File Injection attempt
in ARGS (AE)"] [data "
https://docs.google.com/spreadsheet/formresponse?formkey=dhzsutftwllwzwf6lwd
yb0xcmkzsogc6mq&ifq
"]
[severity "CRITICAL"]
[hostname "lanaddicts.org"]
[uri "/test-form/"]
[unique_id "UAbUbnrJTaEAAHtoboQAAAAG"]

Wow! At first I didn’t know what to make of this. A Google Search led me to this Atomic Corp Wiki. I decided that the Apache Security Module must not like the Google Form URL that I need to carry around through the process in order to submit the form variables to Google. I decided to encode it and then decode it when needed to see if that would satisfy the Apache Security Module.

Guess what?  It works!!!!  This is a big relief as I have another user with almost the exact same error being reported and I am betting my updated plugin will fix their problem too.

If you want to try out an early build while I continue to test, you can find one here.

WordPress Google Form v0.30 now available

Similar to yesterday’s update, today I pushed out wpGForm v0.30.  This version  addresses an unusual problem which prevents the custom confirmation CSS from loading properly.

In some cases, it appears that a plugin or theme, through the use of a filter (likely the_content or wpautop), was inserting paragraph tags into the content which by itself isn’t a problem, however when enabled, wpGForm adds a custom CSS block to style the form during processing, so the CSS definition portion of the content ended up with paragraph tags in it.  This results in CSS which won’t parse correctly and of course it never styles the form.  I have updated the plugin to generate the CSS definition as a single line of text where it previously spanned several lines for readability purposes.

The update should appear on your Dashboard shortly and is also available from the WordPress Plugin Repository.

WordPress Google Form v0.29 now available

Today I pushed out wpGForm v0.29.  This version adds one new feature and addresses an unusual problem which prevents the custom confirmation page, either AJAX or redirection, from loading properly.

In some cases, it appears that a plugin or theme, through the use of a filter (likely the_content or wpautop), was inserting paragraph tags into the content which by itself isn’t a problem, however wpGForm adds a jQuery script to the content during processing, so the jQuery script portion of the content ended up with paragraph tags in it.  This results in Javascript which won’t parse correctly and of course it never runs.  I have updated the plugin to generate the jQuery script as a single line of text where it previously spanned several lines for readability purposes.

Based on several requests, I have added a new short code attribute, sendto=<email address>, which when used in conjunction with email=’on’, will send a form submission note to the specified email address instead of the blog administrator (who is still bcc’d for backup purposes).

The update should appear on your Dashboard shortly and is also available from the WordPress Plugin Repository.

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.

WordPress Google Form Enhancements

Several people have asked for enhancements, many of which are similar. The most common request is to add either pre-filled or hidden fields based on something WordPress knows about. A recent request was to add tracking so a form could only be submitted by a user once. I am certainly not opposed to adding features like these, I think most would be pretty useful. However, there are some things to think about before implementing a solution or adding new features.

  1. To auto-fill a field or populate a hidden field, the field must be mapped from what the column is called on the Google Docs side of the form to something WordPress knows about (e.g. username, email address, etc.). How should this mapping be done? Arguments as part of the shortcode? For anything to be posted to the form processor on the Google side, the field must be defined on the form so the results spreadsheet has a corresponding column. For hidden fields, wpGForm would have to turn what is an existing field (which may or may not be a simple text box) into a hidden field with a value supplied by WordPress. This isn’t impossible, jQuery can do much of the work fairly easily but the problem is it is fraught with potential errors so I am reluctant to add it until I have a better idea how to bullet proof it. Pre-populating values is fairly easy, as long as we know what the field name
  2. I’ve considered, and posted about, introducing a Custom Post Type for forms. If I do this, then it makes addressing the tracking aspect fairly easy because the CPT id could be stored as part of the users meta data. That is pretty straight forward once the CPT exists (which it doesn’t yet). However, it does require the user to be logged into the site which many people don’t want to allow. This could also be handled by the CPT which could in theory, define a new form as anonymous or not. An anonymous form would have some limitations, tracking being one of them.

I’ve got some ideas on how to implement these features, most of which would be pretty useful. Introducing a CPT is absolutely on my radar screen but right now I am focused on my Swim Team plugin as we’re gearing up for Summer Swim Season here in North Carolina. Once I knock out my to-do list on the Swim Team plugin I’ll come back and look at adding the CPT for WordPress Google Forms which would facilitate adding some of the requests people have asked for.

wpGForm v0.28 released

This morning I released an update to my WordPress Google Form plugin.  I can only assume very few people are using the email confirmation feature because it wasn’t working and I didn’t hear about it until this past weekend!  The email confirmation feature (add the attribute email=’on’ to your short code) will notify the WordPress administrator that a form submission has been made.

The update is now committed and should appear on your WordPress Dashboard shortly.

WordPress Google Form v0.27 released

This afternoon I have released v0.27 of my WordPress Google Form (aka wpGForm) plugin.  This release has some new functionality but more importantly, reverts the custom confirmation page to the redirect method which was present from v0.11 to v0.025.

If you prefer the AJAX style custom confirmation, which I do, it is still available by adding the short code attribute style=’ajax’ to your gform short code.

Changes for v0.27 are:

  • Added ability to check and warn for old and/or unsupported browsers. There is an option on the WordPress Google Form settings page to enable this check. When an old or unsupported browser is detected, a message will be displayed on top of the form. The browser check is based on the same functionality that WordPress uses on the Dashboard.
  • Changed default custom confirmation behavior has reverted back to using a javascript redirect as it did from v0.11 through v0.25.
  • Added new shortcode attribute, style, to control how confirmation pages should be handled. There are two options: style=’redirect’ which is the default and style=’ajax’which loads the page content via AJAX.
  • Added new CSS classes to support errors and warnings for the browser check and the inability to load Google Forms.
  • Cleaned up Options page GUI.

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.