wp-SwimTeam

I flew out to Phoenix and back this week and had some airplane time to work on wp-SwimTeam.  I have completed what I am calling “Phase 2″ of the Event Model changes.  Events can now be assigned to a swim meet AND the Opt-In/Opt-Out system is working in the Event Mode (which I had broken in v1.18).

The majority of the work in this build is related to Events and their connection to swim meets which is the precursor to Phase 3 which will be the generation of Meet Entries in SDIF format that can be imported into tools like MeetManager and WinSwim.  I have also fixed quite a few bugs in the report manager which were present when either the User or Swimmer option count was set to zero.  There was some logic that didn’t test right and would result in using the default count which is 5.  So if you have seen checkboxes without labels on the User or Swimmer report generator, this has been fixed.

Please let me know if you run into any issues.  I am doing some testing with our team right now and we have our pre-season open house this weekend which tends to result in a good chunk of our registrations.  Assuming all goes well, I’ll release an update to the WordPress repository early next week if not sooner.

I’ve had a couple requests to support WordPress multi-site installations with wp-SwimTeam.  The Tab Model and Form Processor I use require some URL manipulation to work correctly and my original implementation works fine for “normal” installations but breaks when installed in a sub-directory which is pretty common with WordPress multi-site.  I’ve put off fixing in favor of other things but recently did some work on another project which got me thinking about the URL problem.

After getting the Event Module done I decided to take a look at fixing the URL problem and found it wasn’t too hard to fix.  The bigger problem was how pervasive my broken solution was!  I think I have found every place which required a fix.  Before I release an update I’d really like someone to try it with multi-site and give me some feedback.

This afternoon I released v1.18.747 of wp-SwimTeam.  This release includes what I am calling Phase 1 of the new Event Model.  The event model has been completely overhauled in anticipation of being able to generate Meet Entry files in SDIF format directly from wp-SwimTeam.  The whole Events tab looks and works differently.  Events are collected into what I call Event Groups.  This release adds the ability to import events from a Hy-tek Events File (.hyv).  Events are managed (added, deleted, imported, re-ordered, etc.) within the context of an event group.  In Phase 2 events will be connected to a swim meet via an event group although the swim meet will still retain the ability to re-order the events on a meet by meet basis.

Key features in this release are:

• Phase 1 of overhauled Event Model is complete. The new Event Model introduces the concept of Event Groups. Events are now defined in the context of an Event Group. Swim meets currently do not have any connection to Events but that will chance in a release fairly shortly in Phase 2.
• Added ability to import events from a Hy-tek Events File (.hyv) into an Event Group.
• Added ability to delete all events from an Event Group.
• Changed Google Maps API Key from required to optional. If the API key hasn’t been entered, wp-SwimTeam will now gracefully work without it.

I changed a lot of code in this release, if you run into anything odd or functionality that isn’t working or behaves differently, let me know ASAP and I’ll do my best to fix it quickly.  Now that I am back to a stable code base I should be able to turn bug fixes pretty quickly.  That is hard to do when you’re doing a bunch of remodeling!

This release has been committed to the WordPress Plugin Repository so you should an update notification on your Dashboard.  You can also download it and manually update it from the Download & Installation Page.

Edit (4/16/2012 @ 10:07 AM):  This update includes a database update so you must de-activate and re-activate the plugin after updating to have the database upgrade run.  One of these days I’ll figure out a more elegant way to do this!

I’ve been working on Events quite a bit over the last couple of days.  At this point I have all of the Event Management working again including the ability to import a Hy-tek Events File (.hyv).  I have not gotten to the point where I can connect the events to a swim meet but I don’t think that will take too long.  I will likely release an update with the progress I have to date.  Even with Events unfinished, it actually does more than the old Events Model does.  I have also fixed a few other odds and ends that I’d like to make sure get released sooner rather than later.

As I continue to work away on Event Groups and Event Management overall, I have realized that what I had implemented earlier was really poorly thought out.  The way I had defined events and assigned them to a swim meet really isn’t very useful.  The Event model will change quite a bit as I flush this out.  It is possible that it will be necessary to delete any existing events and redefine them using the new model.  I haven’t completely worked it out yet but that is likely where I am headed.  It makes the code too ugly to try and deal with old data that really isn’t used for anything in the new model.

I hope to have a release soon which has the base functionality done since I’ve also fixed a few other odds and ends while I’ve been in the code.

Last night while I was at my daughter’s basketball practice I finished up modifying the Events functionality to account for the new events groups which will allow events to be bundled into logical groups.  As I was testing everything and things seemed good to go, I realized that the Drag-and-Drop event re-ordering won’t work correctly.

The DnD re-ordering assumes there is only one set of events so as the events are rearranged they are renumbered from 1-N.  This isn’t a show stopper but I will have to come up with a new solution.  In the process of playing around with some ideas I have determined that the jQuery plugin I was using has been updated to support touch so I have folded that in and everything which was working still works.

I had hoped to get a new release out this week but that is unlikely to happen at this point.  I am not going to release anything until I have the event reordering fixed unless I get a serious bug report in which case I’ll simply disable Drag-and-Drop reordering until I get it working again.

This morning I finished up the first phase of Event Groups.  The Event Groups tab will appear on the Management Menu.  The next step is to up date the Event functionality to recognize the new Event Groups.  When I roll this out this update it will require a database update which means deactivating the plugin and re-activating it.

I’ve started on the Event Groups idea I posted about last week. The more I think about this, the more I like it.  In my case, I have three distinct sets of events I have to worry about:  Short Course Yards, Short Course Meters, and our local Invitational which is also Short Course Yards but is a different set of events from what our league normally swims.

By “grouping” a set of events with a label (e.g. Short Course Yards), it will be trivial to assign a set of events to a swim meet.  I have decided to hold off on events import until Events Groups are done so a set of events can be assigned to a group upon import.

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.

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.