Support for multi-page Google Forms?

I received an email the other day about my WordPress Google Form plugin wondering whether or not it should work with multi-page Google Forms  It hadn’t even occurred to me to test it as none of the forms I had needed myself were multi-page forms but my gut reaction was I didn’t think it would work.

I took a look at a multi-page Google Form and have determined that the current (v0.10) version of the WordPress Google Form plugin (aka wpGForm) will not work with multi-page forms.  No real big surprise but I want it to be clear before someone else wastes their time trying to make it work.

From looking at the form code it may be possible to support multi-page forms in the future but it will require some additional jQuery scripting and more importantly, some time to dedicate to it.  I hope to look at this soon but I have a couple of WordPress theme projects that I need to get off my plate before I can go back to wpGForm.

WordPress Google Form v0.10 released

Yesterday I committed the final changes (and still missed a few typos – ugh) to the WordPress plugin repository.  The v0.10 release addresses the problems with required fields on a Google Form.  I’ve heard from several people who’ve told me this fixes the problems they were seeing but if you run into something, add a comment here and I’ll do my best to take a look at it.

Note:  I’ve also changes the beta download link to resolve to the WordPress download so the beta is no longer available.

Form Validation Working!

I have required field form validation working.  I haven’t released it yet but in my testing, it appears to catch all of the fields I defined as required.  WordPress Google Form incorporates the jQuery Validation plugin.

When a page loads, the jQuery script runs and scans the Google form for required fields.  For each required field it finds it adds the gform-required class to the input or textarea tag.  When the validator runs, it looks for fields which have the gform-required class and if any are empty, a label is added with the gform-error class.

The gform-error class is defined in the default CSS to display the text in red and float it to the right of the input.

As can be seen in the image, if there isn’t enough room to the right of the field, the error will be shown just below it.  As with most CSS solutions, there are a bazillion ways to customize the output, I have elected to use something real basic and let the plugin user add more CSS if desired.

If you would like to try this early release of the plugin and give me some feedback, you can download it here.  The version in the WordPress repository is still the older v0.9 release.

[download#7]

 

GForm validation bug PoC

This afternoon I spent some playing with a jQuery Form Validation plugin to determine if it will help me resolve the issue with required fields.  The initial results look fairly promising as I was able to tag a couple fields on a test form and they were flagged when I submitted it.

In the image above, the jQuery Validation plugin added the “Thus field is required” when I submitted the form with those fields empty.   This is exactly the behavior I want, the challenge now is to scale my Proof of Concept (PoC) to work in the generic case of the plugin.  The Google form defines a block for each input field and the class the denotes a field as required is assigned to one of the DIV blocks that wraps the label and form element (e.g. INPUT or TEXTAREA tag) as opposed to the form element tag itself.  This makes finding the required elements a little tricky.

The real challenge I think will be input groups (e.g. radio buttons and check boxes).  I need to do some jQuery research before I have a solution but assuming I can figure out which elements to select, I believe this will solve the problem with required fields.

WordPress Google Form bug with required fields

Google forms allow fields to be designated as required.  When running the form using the standard Google URL, the form will be validated and presented back to the user if any of the required fields are not entered.  There is an issue (aka bug) with required fields in the current version of the plugin.

If a user submits a form that is embedded in WordPress using the plugin, because there are missing fields the form processing does not complete.  There is no indication for the user that something is wrong, the form is simply presented again without any of the fields having data in them.

To resolve this I am looking at doing form validation on the client side using a jQuery plugin.  Hopefully I will have this resolved fairly quickly as I need this to work correctly for my own project.  My testing didn’t take into account a user not completely the form correctly.  Oops.  This bug affects all versions of WordPress Google Form up to and including v0.9.

Stay tuned.

Quick update to wpSwimTeam v1.12.662

There was a typo in one of commits I made over the weekend which resulted in the Opt-In/Opt-Out CC address not working correctly.  This release fixes that problem (which was affecting the MacDolphins).  The release is available from the Download page and has also been committed to the Plugin repository.  It should appear via the Auto-Updater in the next hour or two.

Update: I had the version number wrong in the post title – the correct version is 1.12.662.

wp-SwimTeam v1.10.651 now available

I have tracked down the problem that was causing the opt-in/opt-out list to be displayed incorrectly when called from the wpst_meet_report short code.  I have fixed the problem and made a new release available.  The release is now available from the Download page and has been committed to the WordPress Plugin Repository.  It should appear as an automatic update from the WordPress automatic update process in the next couple of hours.

 

Definite bug in Swim Meet Report short code

There is definitely an issue with the Swim Meet Report, particularly the opt-in/opt-out list, produced by the wpst_meet_report short code.  It produces different results depending on whether or not a user is logged in to the web site and what WordPress capabilities the user has.  I hope to have a solution this morning as it is causing a fair amount of confusion with my own team!

Possible Bug in Meet Report Short Code

I noticed an inconsistency on our meet opt-in/opt-out page (which is based on the short code) earlier this week and it was also seen by another team.  I suspect there is a bug that I need to track down.  In my case the report generated from the short code didn’t include all of the swimmers that the meet report generated from the Options->Reports->Swim Meets tab on the Dashboard included.  In looking at it, the Dashboard report was correct, the short code report was not.  I plan to chase this down in the next day or so.

wp-SwimTeam v1.8.642 now available

Over the past week or so I’ve been working on some new functionality that is finally ready to go.  The opt-in/opt-out module has been based on strokes since the initial implementation and this model worked well for the MacDolphins but some other teams prefer to register (or scratch) swimmers on a per event basis.

Events have been supported for a while but other than adding them to a swim meet, nothing has been done with them.  The existing event functionality is the basis for the results work I hope to complete some day.  Because the Event information is already defined, allowing the Opt-In/Opt-Out module to be based on the actual events was pretty straight forward.  There is a new setting on the Options->Swim Team tab which controls which Opt-In/Opt-Out model wp-SwimTeam uses (Event or Stroke).  By default it will continue to use Stroke since that was the original functionality.

The new functionality had a ripple effect across much of the plugin, causing changes to the Reports module and other places too.  While working on the Reports I decided to expose the Job Assignments and Swimmers Reports for all users however non-admin users will only see their own job assignments or their own swimmers.  This new functionality also came from one of the MacDolphins parents who wanted to be able to see which jobs she had signed up for.  In the same conversation, another parent asked me if I could make it so she could see if she had scratched her swimmers.  These two requests led to exposing some of the Reports in a limited fashion to all users.

The last major feature is the ability to run a report that shows the parents of active swimmers and their status against the volunteer (jobs) commitment set by the team (set it to zero for no commitment).  This is a feature our volunteer coordinator has been after me to implement for some time.  While the Report works fine, it is a little slow, particularly the first time it is run so be patient.

The new version modifies the database tables so PLEASE BACKUP your database before you install it.  I don’t expect any issues and I’ve been running it on the MacDolphins site for the last two days but it is always a good idea to backup your database before upgrading.

There are a few other minor bug fixes and cosmetic changes that I made while working on these improvements.  I ran into one very odd bug that only exposed itself on Chrome – I’ve changed the Load All Events functionality because the Javascript that pulled all of the events from one list box to another didn’t work on Chrome.

There are still some things to improve – I’d like the list of events a swimmer can be registered for be limited to the events for their age group but don’t have good solution for that right now.  I am considering using icons across the action bar instead of the drop down menu.  I had moved away from buttons because they didn’t fit but the dropdown actions are confusing so don’t be surprised to see icons in the near future if I can find some I like!

The WordPress plugin repository has been updated so the plugin should begin to auto-update soon too but in the meantime, you can find the latest release on the download page.