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!

I have a Linux Virtual Machine which I have set up such that I can always run the bleeding edge of WordPress – right out of the Subversion repository.  When a new version of WordPress is ready to come out I update my Linux VM with the current state of WordPress and the current state of wp-SwimTeam and run some tests.

I started doing this a couple weeks ago and got busy and never finished it.  This morning, I got back to it.  It turns out, it didn’t run very well.  Both wp-SwimTeam and phpHtmlLib plugins were calling deprecated WordPress functions.  In releases prior to 3.0, there were no warnings about calling a deprecated function but 3.0 has a new warning feature.  The way it is implemented, the warnings actually caused a failure with phpHtmlLib which resulted in WordPress not successfully loading.

I have fixed the problems in both plugins and committed the changes.  However, I have not released new builds yet so until I do, I advise sticking with the 2.9.x release of WordPress.  I expect a new build later this week at the latest.

Opt-In/Opt-Out

Improvements have been made to the Opt-In/Opt-Out process to make it much less confusing.  The Opt-In/Opt-Out form is now smarter, only presenting the list of strokes to the user when a Partial Opt-In/Opt-Out is selected.  The ability to Opt-In/Opt-Out has also been added to the “My Swimmers” tab to make it easier to find.

Login Redirect

I’ve also added a new option to control what happens when end users login to a site running wp-SwimTeam.  For most users, landing on the WordPress Dashboard page is confusing.  They don’t care about 99% of the stuff presented to them nor should they.  The plugin now allows definition of a login redirect so the user can be sent to either the home page or the Swim Team Overview (which is what I expect to use most of the time) page.  Landing on the Swim Team Overview page makes the most sense for most users since when they login, they are most likely doing some level of interaction with the swim team functionality.

Results Import

Results import is still  in progress, the other two areas mentioned above are complete.  At this point importing results does little more than perform a first pass validation that the supplied file is indeed a SDIF results file.  Now that I have the uploading and validation complete, I need to work on the data model to store results.  Results will be connected to swimmers and meets and events.  Since a new table will be created, results will change the database version when it is released.

Initially I expect to simply report results from a meet and be able to look at results for any given swimmer.  Longer term I want to use Open Flash Chart to plot results on a per swimmer basis over the course of a season or possibly several seasons.  I don’t expect to get to this until much later this year though.

WordPress 2.8.x

I am still working with WordPress 2.7.1 in my development environment.  I haven’t even tried 2.8.4 yet so I have no idea what the impact is.  I will likely do so once I am done with the results.

It took a while to figure it out and with the reorganiztion of SourceForge, a lot of their documentation is either wrong or missing.  SourceForge allows a “persistent” directory for uploads but it isn’t in the htdocs tree – it is in a different area of the file system.  To get uploads working I had to create a uploads directory in the persistent file system space for my project and then create a symbolic link from wp-contents/uploads to the uploads directory in the persistent directory.  Certainly not real striaight forward but at least it is now working.  It shouldn’t be this hard.  I did all of this with sftp, I couldn’t figure out a way to get a shell open via SSH.

While I was at it I also  updated WordPress to the latest (2.6.2) version.

Lighter Menus changes the Dashboard menus into a set of drop down menus.  It is very similar to Andy Staines’ Admin Dropdown Menus.  Unfortunately, Admin Dropdown Menus really changed with the WP 2.5 release and the author has subsequently stated he will no longer support it.  Lighter Menus looked like it might be a suitable replacement so I decided to give it a try.

I really liked the way Lighter Menus works except for one thing:  The custom Swim Team menu didn’t work right.  The URLs weren’t constructed correctly.  Bummer.  But I really liked the way it looked.  Was this the compelling event to fix the growing Swim Team menu?  The Swim Team menu was really unwieldy when using the standard Dashboard as well.

As I worked on phpHtmlLib I tested all of the examples and I kept coming back to the TabControlWidget thinking it might be a good solution for wp-SwimTeam.  The TabControlWidget is a CSS based solution which presents different content based on which tab is selected.

Earlier this week, I decided to try it and see if it would work.  The implementation turned out to be really simple and I was able to use all of individual page code almost verbatim.  I like this implementation much better and I think it is much, much easier to use.  This decision also let me clean up some of the code which had been duplicated between the Admin and User side and resulted in the elimination of a half a dozen PHP file.

My intial impression is it should not be to much of a change as my current database class abstracts the PEAR aspect away from the rest of wp-SwimTeam.  The bigger concern is the phpHtmlLib widgets which also depend on PEAR.   Those will need attention and I suspect I will end up implementing a new database abstraction class for WordPress as part of phpHtmlLib.

I have been doing a lot of work on phpHtmlLib over the last week and for the most part, it appears to be done.  All of the changes allow phpHtmlLib to now be loaded as a WordPress plugin which is much easier to support.

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!