While working on this I found some problems with the Events module which I have also fixed.  One was a very odd case which only was exposed in Chrome as it worked fine under IE9 and FireFox 4.  It turned out to be some sort of a Javascript difference between browsers so I have changed the GUI for the Load Events form.

If you switch from the stroke based model to the event based model for opt-in/opt-out, you may see some empty or unknown events for existing records.  These are due to a non-existent event id in the record.  It doesn’t really hurt anything but does look odd on the report so I plan to look into it.

I am looking for someone to do some testing before I release an update, if you want to help, get in touch with me.

Wp-SwimTeam doesn’t currently support this usage model but I can see the need to do so.  The system already allows the definition and assignment of events to a swim meet, it needs to be extended to allow swimmers to register to particular events instead of the global Opt-In/Opt-Out option which is currently available.

I don’t plan to eliminate the current usage model because it works well for our swim team but I plan to extend it by allowing what I am referring to as the Opt-In/Opt-Out usage model which will either be by Stroke (the existing model) or by Event (the new model).

Fortunately the data model I set up when I first implemented Opt-In/Opt-Out will handle this change fairly easily with one exception.  For some odd reason I called the field in the database which stores the stroke code ‘eventcode’.  This was a bad idea and I am going to change it to ‘strokecode’ in the next release of the plugin which will cause a bump in the database version.  This isn’t the first time I’ve changed a database column name so I am not too worried about it but I wanted to be up front about what I am doing and why.

In the current Opt-In/Opt-Out Stroke based usage model a user can start from a swim meet and update all of their swimmers on a per meet basis or they can start from a swimmer and update all of the meets on a per swimmer basis.  This will remain the case.

However, for the Event based usage model all action will have to be initiated from the swimmer, it will not be possible to update multiple swimmers for a single meet.  This change is due to the swimmers being in different age groups so the events have to be relevant to a swimmer which isn’t possible (or easy anyway, I guess anything is possible) for multiple swimmers.

What about swim ups?  I am not sure how I want to handle swim ups right now.  In the first implementation I will allow an Admin user to register a swimmer into any event but a parent/guardian (standard user) will only be allowed to register their swimmer for the events that correspond to the swimmer’s age group.

Feel free to comment on whether or not I have missed anything and I am looking for someone to validate the usage model once I have it up and running on the wp-SwimTeam Demo site.

Please let me know if you have any problems with this version.  I’ve done a fair amount of testing and I have it up and running on the MacDolphins web site.

The jobs module introduces two new short codes:

• wpst_job_descriptions
• wpst_meet_job_assignments

Example usage of these two new short codes can be found on the wp-SwimTeam demo site here and here.

There is also a new release of the phpHtmlLib plugin which wp-SwimTeam requires available.  This build addresses a minor issue exposed in WordPress 3.0 beta testing.

Hopefully the new Jobs module will be helpful for your team, I know it will be helpful for mine!

While I may not care for Hy-Tek or their products, the fact is they have a dominant market share and a lot of teams use Team Manager, Meet Manager, or both.   I was  contacted this week by a high school coach who was looking for some SDIF assistance in getting his roster into Meet Manager.  Now I don’t have access to Meet Manager but I do have pretty good understanding of the SDIF specification so I was able to help him out with some example SDIF files.

In the process of helping him out I came across an old e-mail regarding importing a roster into Meet Manager.  At the time I was interested in Team Manager so didn’t give it a lot of thought.  Looking at the old e-mail I realized that if it worked, I could export the file format very easily from wp-SwimTeam.  I went ahead an implemented it, now I am looking for someone to try it out.

Sample Reports

The zip file above contains three versions of the same roster – CSV, SDIF (.sd3), and Meet Manager Registration (.re1).  Extract the Meet Manager Registration file from the zip file.  It is an ASCII file that contains swimmers records, one per line with the following fields delimited by semicolons:

1. Registration number
2. Last name
3. First name
4. Middle initial
5. Sex
6. Birthdate
7. Club abbreviation
8. Club name
9. Preferred first name
10. ?? – unknown what this last field is; it’s always “N” in the examples provided

To import the file into Meet Manager, follow these steps:

1. Set up a new meet database.  You only need to go through the first setup screen, the one where you put in the meet name, date, and length of course.  To make my particular file work, select “USA Swimming” for the ID format.  If you have something other than USA Swimming numbers for swimmer labels, select “Other”.  Normally, for a kids’ meet, you’d select “USA Swimming” for the ID format or “Other” if you are not using USA Swimmer numbers for simmer labels.
2. From the main Meet Manager menu, select “FILE”
3. Select “IMPORT”
4. Select “REGISTRATION FILE”
5. Locate and choose the .RE1 file that contains the roster.

After completing these steps, go to the “Athletes” screen in Meet Manager.  The swimmers contained int he RE1 file should bYou should see all of the athletes’ names that you saw in the RE1 file.

If this works for you, please leave a comment!

If you’d like to explore the administration aspect of the plugin, go ahead and register and I will give your User Id the appropriate permissions.  The demo site has been populated with a bunch of dummy users and swimmers and a few swim clubs.  A sample schedule has been set.

One thing about going through the process, it exposed a few things I failed to include in the GUI redesign!  I’ll fix those issues in the next couple days.

This past weekend I started working on a separate plugin that will populate the database with a random number between 25 and 100 dummy users each with between 1 and 4 swimmers, each registered for the current season.  This generation of users and swimmers happens when the plugin is activated.  The plugin can be deactivated and then activated again to add additional users and swimmers.

This plugin was used to populate the database on the new wp-SwimTeam Demo site.

The wp-SwimTeam plugin depends on phpHtmlLib and the 2.x version of the library requires that it be installed in the web site’s root directory.  This typically isn’t a big deal but in some cases can be inconvenient.  It also requires the library be named phphtmllib as the path is (was) encoded into quite a few of the widgets.

When I uploaded the library to the new demo site, it didn’t run correctly.  The demo site is running PHP5 which I immediately suspected as the problem.  So I loaded PHP5 and phpHtmlLib into a new virtual machine (I love VMware, it is wonderful for configuring different environments) and all the examples ran just fine.  Odd, very odd.  Digging into it further, it looks like the hosting provider’s PHP virtual directory support setting is different than what I had locally and affects how include files are handled.

A couple of tests confirmed my suspicions.  Since this hosting provider is large, I suspect this PHP configuration is pretty typical and it provided sufficient motivation to go back and fix phpHtmlLib 2.x so it can be loaded with appropriate configured PHP define() statements.  If you look through the phpHtmlLib forums you’ll find this is a fairly regularly requested item (including by me) and phpHtmlLib 3 (which requires PHP5) is configured this way.

Over the last couple days I have been updating the phpHtmlLib 2.x branch to support this configuration method and now have it all running correctly in my development area.  Before I commit all the changes, and there are a lot of them, I need to verify it all works in the suspect hosting environment.

The trickle down of setting up a demo site resulted in an overhaul to phpHtmlLib.  It needed to be done anyway and doing it will allow phpHtmlLib to be loaded as a WordPress plugin eventually.

If I can set up another instance of WordPress underneath this one to demonstrate the plugin, I will make it available for play with.  I am not sure how to assign new users the necessary permission to admin the demo site since that would provide them a fair amount of control over the actual WordPress install itself.  Hmmm … need to think that through before I turn it on!