Tag Archives: Google Forms

10.17.12
by

CAPTCHA Support for wpGForm

Over the past year one of the most common requests I’ve received is to add some sort of CAPTCHA support to WordPress Google Form.  I don’t deny the need for CAPTCHA but it has never been a real high priority for me personally as I didn’t have a pressing need and more importantly, because Google Forms don’t support CAPTCHA, there wasn’t an easy and/or obvious solution.

However, recently my Help and Support Form has been receiving quite a few SPAM submissions to the point it is annoying.  So now I have a vested interest in finding a solution.

Because Google Forms don’t support a CAPTCHA solution, anything I do has to be done on the WordPress side as part of the short code processing.  This makes it a bit of a challenge because the only way to support CAPTCHA is to add more content to a form.

Essentially what I need to do is generate HTML and insert it into the form and then process it and validate it upon form submission which then can’t progress if the CAPTCHA validation fails.  There are quite a few different CAPTCHA solutions, I wanted to find one that would integrate well with how WordPress Google Form works.

Since I needed to modify the HTML I immediately thought a jQuery solution would be the best bet as (a) I am already using jQuery in several places and (b) what better way to manipulate HTML than using jQuery!  A Google search yielded this list of 10 jQuery CAPTCHA plugins.  After looking through them I leaned toward QapTcha however in investigating it, using QapTcha would be a little more involved that I wanted.  I also considered jQuery Real Person but eliminated it as too cumbersome to integrate.  I may go back and look at these two again as both are interesting but both are more invasive than I was willing to take on right now.

I subsequently found another list of 10 jQuery CAPTCHA plugins.  This list had some overlap with the other list but one entry caught my eye:  #6 –  jQueryValidate Plugin plus PHP equals CAPTCHA  It caught my eye because I had previously used the jQuery Validate plugin within WordPress Google Form for validating required fields (it was eliminated later when it was no longer necessary as validation came from Google when I added support for multi-page forms).  After reading the article, I realized I could very easily implement a similar solution and more importantly, I could resurrect the jQuery Validate code from an earlier version of the plugin.

So that is where I am headed.  Getting an initial CAPTCHA on the page was pretty simple.  What proved to be the challenge was to only display the CAPTCHA when the Submit button is present.  It took me a little while to figure out the jQuery selector but as I write this post, I have the basics of a simple math CAPTCHA working for both single page and multi-page Google Forms.

I have decided to add the fields using the same classes that Google uses for their forms so any styling done using the Google CSS rules will also apply to the CAPTCHA fields.

If you want to test this out before I release it feel free to get in touch with me and I’ll make an early build available.  By no means is this solution fool proof but it should help eliminate some form SPAM and that is what I am currently trying to do.

10.16.12
by

Two Google Forms on one page?

A user of my WordPress Google Form plugin brought me an interesting problem to look at. He wanted to put two forms on one page. The forms were each placed in a DIV and then visible to the user based on which tab on the page was selected. The presentation isn’t really germane to the problem as under the hood the page had two forms on it.

What does this mean to WordPress Google Form?  Right now it means there is a bug (which I have fixed but not yet released) that results in a Javascript error.  The Javascript which manipulates the check boxes is added once for each form and run once for each form.  As I noted above, I have already fixed this bug and it has been tested on a live site.

However, there are still a couple of other things to sort out when more than one form is present which is why I haven’t released an update yet.  These are the things I am struggling with:

  • If the alert shortcode attribute is used, the alert from the first short code is always displayed.  What is desired is the alert from the submitted form should be displayed.
  • The HTML provided by Google which is used to build the form has a FORM element with an ID of “ss-form”.  This is not an issue when there is only one form on the page BUT is technically invalid HTML when two elements have the same ID.

I am not sure what to do about the second issue.  It wouldn’t be hard to manipulate the HTML so the FORM element ID is unique but I don’t know if it is used on the Google side and it could also result in CSS issues if rules have been defined based on #ss-form.

I am considering adding a new shortcode attribute to override the FORM element ID value.  I think this is the safest way to do it but really know if there are any ramifications on the Google side until I try it.

As for the alert, I think I need to track which form is submitted and detect which alert should allow me to generate the Javascript for the correct alert.  I am less worried about this issue than the FORM element ID issue.

While I am digging around in the code, I am also looking at CAPTCHA solutions.  The lack of CAPTCHA is a bit of a problem with Google Forms and it isn’t a simple problem to solve.  What do you do on multi-page forms?  CAPTCHA on every page?  CAPTCHA only on Submit page?  I think the later but that is a little harder to detect.

10.02.12
by

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.

09.27.12
by

Time to add Captcha support for wpGForm?

I’ve had my Help and Support form for my WordPress Google Form plugin online since April and it has greatly improved my ability to help people use my plugin. I get all of the information at one time where as before it took several passes via email to get all of the data I typically need to resolve an issue.

Up until about two weeks ago, I never got any spam via the form but lately I’ve been receiving 2-3 form submissions per day that contain nothing but gibberish.  So it got me thinking about how to implement a Captcha solution.  A Captcha solution has been requested several times and I’ve never looked at it seriously because (a) Google doesn’t support it and (b) it wasn’t something I thought was terribly important.  I am rethinking my position how important it is!  😉

The fact that Google doesn’t support a Captcha solution is the biggest hurdle.  The challenge is to add the necessary code to the HTML generated by Google, recognize and process the Captcha, and it is passes, remove the Captcha input prior to submitting the form values to Google for processing.  This becomes a more complicated issue on a multi-page form:  Does every page have a Captcha or only the last page with the Submit button?

I don’t have a solution yet but this is something I am noodling on as I have some spare cycles.  The solution will almost certainly be jQuery based, I can’t think of a better way to do it and I am already using jQuery to process radio button inputs so they can be converted from PHP style inputs on the WordPress side to Python style inputs on the Google side.

09.14.12
by

WordPress Google Form v0.39 released

This morning I released v0.39 of my WordPress Google Form plugin.  This update addresses the corner case exposed when using WordPress Google Form with the Unite theme from Paralleus.  To solve this incompatibility I’ve introduced a new short code attribute called unitethemehack which defaults to off.  By turning it on, WordPress Google Form will modify the Google Form HTML to protect the Submit button(s) from being manipulated by the Unite theme.

You can find this update in the WordPress plugin repository or as an update on your WordPress Dashboard.

09.14.12
by

Debugging a Theme conflict with wpGForm

About a week ago I was contacted through my WordPress Google Form Support and Help form by a user of my WordPress Google Form plugin.  The symptoms he described sounded very much like the problem I recently chased down with ModSecurity.  I figured this must be another use model that I hadn’t accounted for.

Fortunately and unfortunately, I was wrong.  After going through the usual process of trying to narrow down the problem (using wpGForm debug mode, disabling all plugins, etc.), we were able to isolate the problem to what I suspected was a theme issue.    Ugh.  A lot of times people don’t want to or can’t change their theme. I wanted to swap the theme for TwentyTen or TwentyEleven but that wasn’t really possible as the site is live and being used.

Now what?  Since the user couldn’t switch the theme and we ended up putting a copy of his theme in a development area and were able to replicate the problem.  Whew – the helped a lot.  I could switch back and forth between his theme and TwentyTen in debug mode and compare the results.

It took a while to track it down but it turns out the theme, Unite from Paralleus, has a jQuery script which scans the page content for Submit Buttons, removes the buttons, and rebuilds them to match the theme style.  In theory this is actually rather clever and makes the submit buttons attractive although I am not sure why it couldn’t be done with CSS classes, I didn’t look at it closely enough.  However, in practice when the submit buttons are reconstructed, they don’t contain all of the attributes they started with so they are not equivalent.  And this matters when submitting a Google form.  A lot.

A Google form just can’t be submitted with a submit button.  It needs to be submitted with the submit action having a named parameter and a value.  Google uses the named parameter and it’s value to support multi-page Google forms.  It is this named parameter and value that Unite strips off effectively making the form incomplete which causes Google to rejects it as an incomplete form.  Because Google rejects it, WordPress Google Form simply redisplays the form again.  To the end user it looks like the form was never submitted.

As a plugin developer, I am not sure what the right answer is here.  Actually, that isn’t true.  I do know the right answer is.  The theme should be fixed but I have zero control and influence over that happening.  To solve the problem in the short term, I have created a hack of sorts that works around this problem with the Unite theme but that is in a one-off build for testing.  What should I do to my plugin?  Add a unitethemehack=’on’ attribute?  Right now that is probably the best option although it feels pretty dirty.  The code to enable this hack is trivial because Unite won’t muck with submit buttons which have the noStyle CSS class applied to them.  At least there is a work-around.  The hack I added to WordPress Google Form is inserting class=”noStyle” to any submit button in the Google Form HTML.

But I am wondering how many more scenarios like this will I run into?  Is there a more general purpose solution?  Probably.  I’ve been thinking about a “find and replace” solution as I was asked about doing something similar previously to rename all of the submit buttons as something else.  I’ll keep noodling but for the time being, I think I’m going forward with a new attribute.

09.07.12
by

WordPress Google Form v0.38 released

Today I released v0.38 of my WordPress Google Form plugin.  If you look at the change log you’ll see I actually released it a couple times today (ugh).

Release v0.36 addressed a bug when the Browser Check option was enabled.  I susquently released v0.37 because I didn’t tag v0.36 correctly and the WordPress Plugin Repository didn’t see the update.  I then released v0.38 because I left some debug code active that I used to chase down the problem I originally fixed in v0.36.

I apologize for the multiple updates, it certainly was not my intention.  You can find v0.38 on your Dashboard Update or in the WordPress Plugin Repository.

09.05.12
by

WordPress Google Form v0.35 released

This afternoon I released v0.35 of my WordPress Google Form plugin. Included in this update are:

  • Minor fix to email formatting to address poorly formed HTML.
  • New short code attribute (spreadsheet='<url>’) which, when used in conjunction with the email=’on’ attribute setting, will include a link to the Google Docs Spreadsheet which contains the form submission data.

You can find the latest version of WordPress Google Form in the WordPress Plugin repository or as a Dashboard Update.

08.28.12
by

Finally fixed the Multi-Page Google Form results

Since I first added support for Multi-Page Google Forms I have had a sample form on my site with the submitted results displayed on another page. I use the Inline Google Spreadsheet Viewer plugin to display the submitted results on the page except it wasn’t working.

It worked fine for my Sample Form results but not the Multi-Page Form results. I finally figured out that I was using the wrong Google Docs key to display the results. I was using the key that Google Doc’s Share functionality provides instead of the key that the Publish to Web Page provides.  It is this later key that allows the plugin to operate correctly.  Doh!  Need to read the documentation a little closer I guess.

08.13.12
by

WordPress Google Form v0.33 released

This afternoon I released the v0.33 update to WordPress Google Form.  This update introduces a new setting which allows users who are using the email notification to turn off the Bcc to the Blog Admin feature.  This setting is on my default to match the behavior of the plugin prior to v0.32.

Several other minor bugs were also fixed which affected how default plugin settings are handled.  You can find the update in the WordPress Plugin Repository or on your WordPress Dashboard Update notification.

What happened to v0.32?  I failed to update the version number in the plugin file before tagging the relase in the WordPress plugin repository so I had to increment the version number again.