If you updated to any of the wp-SwimTeam v1.16.x releases you must update again to v1.17.707. I inadvertently introduced a bug which prevented almost all of the registration (season, swim meet, etc.) actions. I quickly fixed this bug once I became aware of it, I apologize for any inconvenience.
Monthly Archives: March 2012
wp-SwimTeam v1.16.704 now available
This morning I posted an update to wp-SwimTeam.
This release fixes a couple more places where the first and/or last name should appear but was being displayed as “N/A”. It turns out I had re-used the same code which I had fixed a couple weeks ago in some other spots so the problem was the same. This time I fixed it by moving the solution down into a parent class and eliminated a bunch of redundant code. Hopefully it is gone but there is an outside chance I missed one.
Anyone who has used wp-SwimTeam may recall that the actions used to be buttons across the bottom of the widget I frequently use to display data. This worked well until I had more actions than I had room for buttons. My solution was to move the actions into a drop down list and many of the tabs used this model. This release reconciles the inconsistencies so all tabs now use the drop down action model.
I have started work on some of the event changes I have posted about, hopefully I’ll have some new functionality in the next week or so.
phpHtmlLib v2.6.3.3563 released
This evening I released a new version of the phpHtmlLib plugin which wp-SwimTeam depends on. This update addresses a number of PHP5 deprecated function warnings which are commonly seen when running under PHP5 with E_STRICT set. I also fixed an icon bug which appeared on the GUI widget used across wp-SwimTeam when there was no data to display.
The update also removes the documentation and examples from the version of the plugin hosted in the WordPress plugin repository since they are only useful for developers. A full version of the plugin including documentation and examples can be downloaded from the Download & Installation page.
Possible Enhancements for wpGForm
Recently I have had a couple requests for enhancements to wpGForm. One of the recent ones was the ability to define hidden fields on a form to capture some data from a WordPress user.
Currently Google’s forms define fields like this:
<input id="entry_0" class="wpgform_ss-q-short" type="text" value="" name="entry.0.single">
It would not be too hard to add an attribute like hidden=’entry_0,entry_2,
entry_27′ to the shortcode. I could even do something like
hidden=’entry_0=email,entry_2=username,entry_27=first_name,entry_28=last_name’ where the “allowable” presets would have to map to the fields which can be returned by get_userdata() see:
http://codex.wordpress.org/Function_Reference/get_userdata Of course all of this predicates that the user is logged in so those fields exist.
I’ve also considered changing the plugin to allow for more complicated things – adding more options to the shortcode could get pretty cumbersome. What’ve I thought about is doing leveraging the Dashboard (using a Custom Post Type) to Manage Forms where you “Add” a form and the Dashbaord provides a GUI where all sorts of information would be added:
1. Form URL
2. Confirmation URL
3. Switches for all of the other options (legal, read-only, etc.)
4. More things I haven’t thought about
Forms could then be “Edited/Deleted/etc.” just like other post types. Then you’d simply embed the form using a simple shortcode like [wpgform id='1']. The rest of the information would be stored inWordPress as custom Post Type fields. I’d probably define a new shortcode for this so the current one would continue to work but that is the general idea.
Thoughts?
Re-Thinking Events
Nothing like a long flight to provide an opportunity to really look into wp-SwimTeam! After fixing a couple more bugs, I started looking at Events as they are the foundation of meet entries.
A couple years ago I added Events to wp-SwimTeam but they don’t really do much. It was the start of some new functionality that I never had the time to finish as fixing or enhancing other aspects of the plugin were always more important.
This season I really want to add the ability to generate a Meet Entries file directly from wp-SwimTeam. In order to do that, the first order of business is to make sure the events associated with a swim meet can be managed.
Which brings me back to Events. In looking at Events, the functionality I originally built is ok but has what I see as one pretty serious gap. I allow the creation of a set of “Standard Events” –events which you can consider the base set of events that your team will swim most often, probably your home pool events. This is ok because they can easily be added to an individual swim meet.
But what happens if you have a pool, like our home pool, which is measured in Meters and all of your opponents swim in Yards pools? Even if the events are the same, you’d probably like to have a standard set of Meters Events and a standard set of Yards Events. Now if I am going to manage two groups of Events, I might as well manage N groups of Events right?
I am toying with the idea of adding another field to the events table (Event Group) which would allow events to be assigned to a group. Groups could be optionally defined (default to None). Once Events are in a Group a Group of Events could easily be assigned to a swim meet. Additional refinement at the swim meet level would still be supported.
I also plan to support the ability to import a Hy-tek Event File (.hyv) to either a specific meet or as a set of standard events.
I’ve got a couple more hours of flight time to noodle on this, we’ll see where it goes.
Can’t add new Swim Team Job?
I ran into a problem this past week that I am not sure will affect anyone else but my own swim team. Our volunteer coordinator let me know that she was unable to add new jobs. I couldn’t replicate the behavior in my development area which required me to debug it on the live server (ugh).
Because most of the things I add and/or changes I make to wp-SwimTeam are for the MacDolphins (but not always), I usually test them on the MacDolphins web site before releasing an update. When I first added the Jobs module to wp-SwimTeam I had defined column names in the database table. At some point I decided to be more descriptive with my names and changed the column names. I think, but I can’t be sure, that I did this before publicly releasing the plugin update. WordPress usually, but unfortunately not always, handles database schema changes correctly and will change column names.
In my case, WordPress, for whatever reason, didn’t change the column name, it defined a new one. While this isn’t of itself a real problem, having a few unused columns in the database isn’t preferred, it isn’t a real big problem either. Except that the default value for the column was never defined (oops) and at some point, MySQL (maybe MySQL5) started to care that the column wasn’t initialized.
The net result was we was we were unable to add new jobs because MySQL was returning an error message due to the uninitialized column that wp-SwimTeam wasn’t accounting for. The simple solution for us was to simply delete the columns that shouldn’t have been there in the first place and won’t ever be there for people using the plugin now.
In the process of chasing this problem down, I found an area of my database interface where I wasn’t properly accounting for possible database errors. I have updated the database interface class and the Jobs module which sits on top of it. Over time I will also retrofit this change into other parts of the plugin as I work on them.
Look for a plugin update to be released in the next day or so.