Category Archives: Plugin

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.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.

06.25.12
by

The Magic of the get_users() Function

While working on Email Users recently I encountered a performance problem with some SQL which I had received via the WordPress Hackers Mailing List back in January of 2008.  At the time I needed it for my wp-SwimTeam plugin (where I am still using it) and it served me well.  When I first committed a patch for Email Users (v3.4.0) I used this SQL to allow sorting of the users as prior to v3.4.0, only the usernames were displayed.

It turns out this SQL is pretty inefficient (I am by no means an SQL expert) and it was causing performance problems for people using Email Users with a large number of users.  Again I turned to the WP Hackers Mailing List and received some significantly improved SQL.

The ensuing discussion also recommended migrating my SQL to the WordPress API get_users() function.  I am all for using the API when I can as it is much safer and typically much easier to work with.  In this case, I couldn’t understand how it would help me retrieve the first and last names from the Meta table that I needed.  It wasn’t mentioned anywhere in the Codex so I was confused.

A subsequent post in the thread mentioned the “magic” of get_users() which I then tried and sure enough, the data I wanted was available.  Ok, now I am really confused.  Where does this magic data come from.  Fortunately another post referenced this article which explains how these magic methods work and why the data is available.  This is pretty neat and very useful although I have no idea how developers would know this exists based on the documentation in the Codex.

These “magic methods” strike me as one of those “inside baseball” things that not being a full time WordPress developer I’d never know about.  It is very useful and something I’ll certainly remember and use in the future.  Thanks to the WordPress Hackers Mailing List – an incredibly valuable resource.

06.06.12
by

I am now contributing to the E-Mail Users plugin

I am happy to say that I have been granted Subversion commit access to the popular Email Users plugin.  I have been using this plugin for a number of years and have submitted several patches which were included in the 3.4.x releases.  Recently I needed to add some functionality to support the MacDolphins web site and use of the plugin and after submitting a patch, I was invited to be a contributor by Vincent Prat at Marvin Labs which I gladly accepted.

The 4.0.0 release of Email Users is a pretty substantial change.  It updates the plugin to use the WordPress Options API and updated menu API.  It also adds a new feature that allows easy access to managing the email options for one or more users.  No more visiting the User Profile for each user, bulk actions are now available!

More to come over the next few days.

05.31.12
by

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.