This is my short list of items which I want to implement this season:

1. New/update Swim Team theme.  This really isn’t related to wp-SwimTeam per se but our site is looking a little dated and it is time to freshen it up.
2. Results Import:  I said I was going to do this last season and I never finished it.  I really want to get this done this year.
3. Export of Meet Entries:  The wp-SwimTeam plugin has all of the informtation (roster, scratch list, event list, etc.) to generate a Meet Entries file in SDIF format.  Providing this file will greatly simplify getting a team’s entries into either Hy-tek or WinSwim (or any other tool which imports meet entries).  This will likely be first on my list after fixing the name bug and the GUI inconsistencies.
4. Document all of the short codes on the wp-SwimTeam demo site.  I really need to do this.  It would make it much easier for new people to pick up the plugin and do something useful with it quickly.

This release has also been pushed to the WordPress plugin repository so it should be available via the plugin updater fairly soon.

I have set up projects in the official WordPress plugin repository for both wp-SwimTeam and phpHtmlLib.   I am working on a process where the plugin updater will work by adding the code into the WordPress repository when Iam ready to release it.

Currently the version of the code in the WordPress repository is the same as what is available for download although the version number reported is wrong (1.0.553 vs 1.2.553).  The “553″ is the critical part of the release number because it represents the Subversion commit number (build number) that the release is based on.

If you see a “plugin out of date” message within the WordPress Dashboard, it is because I am working on this process.  The latest and greatest release will likely be available first as a download on this site but when I reach what I consider a “stable” release, I will also make it available through the WordPress plugin repository.  Stay tuned as this flushes out.

I called GoDaddy this morning to see why my sites was loading so slowly – I am seeing page load times of 30-40 seconds which is just plain silly.  It looks like another web site that I happen to be sharing the “shared” server with is consuming all of the resources.  GoDaddy is going to monitor it and see what is up.  I expect it will remain slow for at least a few days.  Hopefully they’ll figure out what it is and do something about it but they did tell me that if the other site isn’t violating their TOS, there isn’t much I can do about it.  They also suggested I look into a WordPress caching plugin.  I don’t have near the volume of data nor traffic to warrant a caching plugin but if the situation persists, I’ll look into it.

Bleh.  Even on a shared server there ought to be some expectation of “reasonable” performance.  I will continue to monitor the performance and see what I can do about it.

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.

I am considering pulling it into the plugin as SVN external.  This would allow me to ensure it is always installed.  Doing this will greatly simplify the download and installation process for the end user as well which ultimately will make it easier to support users of the plugin.  The more I think about it, the better idea I think this is.  I need to read up on SVN externals!

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!