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.

wp-SwimTeam v1.21.790 released

This morning I released v1.20.790 of wp-SwimTeam.  This release addresses a bug which only appears on some hosting configurations where the URL http://www.example.com and http://example.com don’t resolve to the same place.   It isn’t clear to me why the server variables sometimes truncate the prefix but in some cases it happens and in some cases it makes a big difference.

Thanks to a couple teams for letting me access their site and chase this problem down as it doesn’t happen on my own sites.  This version makes use of the WordPress API (which I probably should have done that in the first place) to construct URLs for the tabs instead of parsing the PHP server variables. I’ve done a fair amount of testing on four different sites over the past 24 hours so I feel pretty good about the new implementation.

I have also incorporated this URL fix into the construction of the links on the Tabs for the Swim Team, Manage, Reports, and Options pages.  While I wasn’t having a problem here, the new solution is the “correct” way to construct the URL and should be more robust in different WordPress configurations.  WordPress has already figured out the various server configurations, no need to reinvent the wheel!

The update has been pushed to the WordPress Plugin Repository so you should see an Upgrade notification on the Dashboard soon if it isn’t already there.  This build is also available from the Download and Installation page.