Monthly Archives: January 2012

01.30.12
by

Yet another update! WordPress Google Form v0.18 available

I have just released another update to the WordPress Google Form plugin.  Within the HTML code that Google generates for their forms, each input field has  unique identifier (e.g entry.0.group, entry.47.group, entry.6.single, etc.).  There was a bug in the Regular Expression which incorrectly handled these identifiers when then had more than one digit.  This bug is fixed in v0.17.

Why do the identifiers need to be processed?  The need to “massage” the identifiers is due to the fact that WordPress is based on PHP and Google Forms are processed by Python.  The two languages handle passing form parameters slightly differently.  When the form is submitted on the WordPress side, the periods in the id are translated to underscores by PHP.  Inputs like check boxes which may contain multiple values are handled using arrays in PHP where as Python allows the use of the same identifier multiple times.  In order to submit the form values to Google, any value received as an array must be converted to a multi-value and the underscores need to be translated back to periods so they match the Python script on the Google side which actually processes the form and stores the result in a Google Spreadsheet.

There was a mistake in the logic which transforms the identifiers from PHP syntax to Python syntax.  It didn’t correctly handle more than one digit in the identifier resulting in the wrong identifier names being sent to Google.  This also caused loss of input values when a required field was not supplied.

Hopefully this will be the last problem!

01.29.12
by

WordPress Google Form plugin v0.16 released

This morning I uploaded a new version of my WordPress Google Form plugin.  This update addresses the three items I noted in this post.  I also expanded the Test Bed Form I have  been using to develop and test the plugin.  If you’re curious, I have added the form to a page on this site.  If you run into a combination that isn’t working and I haven’t accounted for it in the test bed, please let me know and I’ll update my form.

I think I finally have Check Boxes working correctly.  They were a challenge because how PHP (which WordPress uses) pass arrays of information and Python (which Google Forms use for processing) are very different.  Thanks to a tip on the WordPress Hackers Mailing List to a utility called http://httpbin.org I was able to get my plugin to pass the parameters as Google expects them and everything seems to be working correctly.  The update should appear in your WordPress Dashboard fairly soon.

01.28.12
by

wpGForm Bugs in v0.15

I have been alerted to a couple of bugs in the current (v0.15) version of wpGForm that I am working on fixing.

  1. Select boxes do not retain their value when going back on multi-page forms.  I’ve already fixed this problem in my development build.
  2. Check boxes are not passing their values correctly.
  3. Sometimes Radio buttons do not retain their values when going back on multi-page forms.

This third item is proving difficult to track down. It is odd that some questions with radio buttons work fine going back and forth between pages but others do not.  If I can fix the check boxes this morning I will likely release an update that addresses the first two bugs and keep working on the third problem.

01.26.12
by

Why Doesn’t My Form Render?

I typically get asked questions several times a week from people trying to use my WordPress Google Form plugin.   The most common problem I see is incorrect shortcode syntax which isn’t real obvious.  If you use the visual editor (which I do) when composing a post of page which includes the gform shortcode, pasting the URL for the Google Form will frequently include the pasted text as a link.  Take a look at these two images.

 

At first glance the text appears the same and there doesn’t appear to be anything wrong with the shortcode syntax. However, the first one will not render because it has a link embedded in it.  As I said – not real obvious but leaving the link in will result in an error when trying to render the form.

Removing the link is easy, simply click anywhere within the link and use the Remove Link icon (broken chain) and you’ll end up with shortcode syntax similar to what you see in the second image.

01.24.12
by

Gearing up for Swim Team 2012

It will be summer swim team season before I know it so it is time to start gearing up for the upcoming season.  I haven’t really looked at wp-SwimTeam since last fall and WordPress has had several updates since then. I found out today that one of the updates causes the “real name” for the users not to be returned so that is first on my list of things to fix.  There are also some GUI inconsistencies that I’d like to fix.

This is my short list of items which I want to implement this season:

  1. New/update Swim Team theme.  This really isn’t related to wp-SwimTeam per se but our site is looking a little dated and it is time to freshen it up.
  2. Results Import:  I said I was going to do this last season and I never finished it.  I really want to get this done this year.
  3. Export of Meet Entries:  The wp-SwimTeam plugin has all of the informtation (roster, scratch list, event list, etc.) to generate a Meet Entries file in SDIF format.  Providing this file will greatly simplify getting a team’s entries into either Hy-tek or WinSwim (or any other tool which imports meet entries).  This will likely be first on my list after fixing the name bug and the GUI inconsistencies.
  4. Document all of the short codes on the wp-SwimTeam demo site.  I really need to do this.  It would make it much easier for new people to pick up the plugin and do something useful with it quickly.
01.17.12
by

WordPress Google Form v0.15 released

This morning I fixed the problem with the default settings which caused any of the settings which are on by default, to be on no matter what.  Even when the user would turn them off, the plugin would ignore the user setting which was being saved correctly, just ignored being ignored by the during the default check.

I also finished removing the jQuery-Validate plugin as it is no longer used as well as a bunch of debug code and functions which are no longer used.  Updates should appear on your Dashboard soon and it is already available for download in the WordPress plugin repository.

01.17.12
by

WordPress Google Form Bug with default CSS

There is a bug with the current (v0.14) version of WordPress Google Form in that it will always load the default CSS that is shipped with the plugin.  Using the setting to disable loading the default CSS is not saved so it is never turned off.  I am looking into this issue and will post an update as soon as it is fixed.

01.14.12
by

Quick bump to v0.14 for WordPress Google Form

While looking at a CSS styling problem for someone I encountered a minor bug on the Options page.  The plugin wasn’t picking up the default options correctly and in some cases a PHP array index warning would appear on the Options page.  This bug has been fixed and I’ve released v0.14.  You can download it from the WordPress plugin repository or update it from the Dashboard.

01.14.12
by

WordPress Google Form v0.13 fixes “back” bug

I have just committed v0.13 to the WordPress plugin repository.  An update should appear in your WordPress Dashboard fairly soon.  This update fixes a problem when using multi-page Google Forms which have radio buttons and check boxes on them.  When the “Back” button was selected to view the previous page of the form, the previously selected values were not retained.  This bug has been fixed and the “Back” and “Continue” buttons now work as expected.

01.12.12
by

WordPress Google Form v0.12 is out

Yesterday I committed and tagged the v0.12 release of my WordPress Google Form plugin.  It is available from the WordPress plugin repository.  The main feature of this release is support for multi-page Google Forms.  The changes made to support multi-page forms should also enable use of fields that have optional answers.

There is still some leftover code from the old validation process that I was reluctant to completely remove until I know for sure this new architecture is working in more use cases than I have to test with.  There will likely be another update that is nothing more than a code clean up in a couple weeks unless someone reports a problem.