WordPress Google Form v0.45 now available

This afternoon I released v0.45 of my WordPress Google Form plugin.  After validating the changes I made in the beta with a user who was dealing with a polluted jQuery script, it looks like moving the jQuery script into the WordPress footer action is the right answer.

You can find the update in the WordPress Plugin Repository or as an update on your WordPress Dashboard.

WordPress Google Form v0.45-beta available

I’ve made a subtle but potentially significant change to WordPress Google Form that I am looking for some people to try out.  The plugin generates a jQuery script on the fly to perform a number of actions depending on the shortcode attributes present and their setting.

Historically the jQuery script has been output as part of the form code but I’ve seen a number of cases lately where another plugin or in some cases, the theme, is manipulating the page content which ends up affecting the jQuery script.

In one case I looked at this weekend something, I am still not sure what, is injecting paragraph elements into the HTML after it detects a closing DIV tag.  For the most part this isn’t a big deal except, there are closing DIV tags in the jQuery script as part of the CAPTCHA functionality.  The CAPTCHA functionality injects a DIV which holds a second DIV and some other input elements and labels.  What ever is injecting the P elements into the HTML after every closing DIV is causing my script to have syntax errors when the page loads.

To solve this problem I have moved to loading of the jQuery script into the WordPress footer action.  In my testing making this change  has zero effect on the functionality but I’d like some other people to test it and provide me feedback.

Google Forms Beta (490 downloads)

WordPress Google Form v0.44 now available

This morning I released v0.44 of WordPress Google Form.  This is a minor update which addresses a problem reported in the WordPress Plugin Support Forum.  This update fixes the problem where the settings which are on by default, cannot be turned off.  You can find the update in the WordPress Plugin Repository or as an update on your WordPress Dashboard.

WordPress Google Form v0.43 now available

This evening I released v0.43 of my WordPress Google Form plugin.  This update addresses a couple of bugs and fixes a few more issues with the optional CSS prefix.  It also addresses a potentially serious problem when using Debug Mode with PHP version prior to 5.3.

  • Reimplemented shortcode attribute br=’on’ usinq jQuery instead of preg_replace().
  • Reimplemented shortcode attribute legal=’off’ usinq jQuery instead of preg_replace().
  • Fixed DEBUG mode so it will work with PHP 5.2 (which doesn’t support anonymous functions).
  • Fixed CSS prefix bugs which prevented CSS prefix from being applied to all Google CSS classes.

WordPress Google Form v0.42 now available

This morning I released v0.42 of my WordPress Google Form plugin. This version fixes a number of minor bugs, one major bug, and adds some new functionality. Of particular note is the ability to add a CAPTCHA to your Google Form to help reduce SPAM form submissions.

  • Added simple math based CAPTCHA support.
  • Reintroduced jQuery Validation for checking required fields.
  • Improved support for multiple forms on one page.
  • Fixed several bugs where CSS prefix, when used, was not output in some places.
  • Moved Debug control to its own tab on the settings page.
  • Added new Debug options to facilitate chasing down HTTP API issues.
  • Fixed bug where the CSS prefix, when used, was not being applied properly to elements which had more than one class. Only the first class was properly prefixed.

You can find the update in the WordPress Plugin Repository or as an Update on your WordPress Dashboard.

WordPress Google Form v0.41-beta available

This afternoon I made a beta version of WordPress Google Form v0.41 available for download from this site. I have not posted this version to the WordPress plugin repository yet as I’d like to get some additional testing done on it before doing so.

There are a could of significant new features and a few bug fixes in this version.

  1. Simple CAPTCHA!  You can now add a  simple math based CAPTCHA to a Google Form to help prevent SPAM form submissions.
  2. Improved support for multiple forms on one page.
  3. The return of jQuery validation for required fields.  This validation is optional but since I used the same jQuery plugin to implement the CAPTCHA solution, I figured I may as well make it available for required field validation again.  It works the same way it did in the initial plugin implementation until is was removed with the support for multi-page forms.
  4. New Debug options on a separate Settings tab.
  5. Several more bug fixes, notably for custom CSS prefixes.

Download the beta release and please let me know if you run into any issues.  You can see an example of the CAPTCHA and new Validation options on my Test Bed Form.

Google Forms Beta (490 downloads)

CAPTCHA is working!

I work much better in the early morning than I do at night.  Always have.  Last night I was working on CAPTCHA support for WordPress Google Form and for the life of me, couldn’t figure what was causing a jQuery syntax error.  Granted, working on my laptop in my truck in the dark while at my daughter’s soccer practice isn’t the ideal work location but that was my situation when I had some cycles to look at it.

This morning I looked at it again, made one minor change and the syntax error was obvious.  Syntax error fixed and my CAPTCHA solution appears to be working.  I am going to clean up some debug code and then post a beta release for testing.  Hopefully I will have this formally released in the next day or two.

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.

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.

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.