Better Solution for Event Ordering

I haven’t made much progress over the last few weeks as I have been working on a project at work which was taking a lot of my free cycles.  Fortunately the project at work also uses phpHtmlLib so some of the work I did for the work project will roll out to this project as well.

Even though I haven’t put a lot of active cycles into wp-SwimTeam, I have been looking for some ideas on how to deal with event ordering better.  Event ordering was one of the last things I checked in and I went back and used it and it is clunky.

I have concluded that Event Ordering and ultimately heat sheet management needs to be AJAX based so drag and drop can be implemented.  I want to implement something similar to this jQuery Portlet demo.  Since I have never done anything with AJAX (other than a Google Maps implementation), this is new ground for me.

wp-SwimTeam demo up and running

I have spent quite a bit of my free time lately re-working my wp-SwimTeam WordPress plugin in a quest to get a demo site up and running.  In the process I changed quite a bit, some because I had no choice, some because I was knee deep in the code and decided it was time to fix some things I wasn’t real happy with.

A lot of the work involved working with Google Maps API.  The Google APIs are really pretty cool, if you need to do some work with AJAX or Javascript, they are worth looking into.  I ended up using the new Google AJAX API (which can load the Maps API) and the new syntax.  There seems to almost no performance degradation from loading Google’s JS libraries as compared to loading them directly from the host site.

A bunch of the work was neccessary because GoDaddy, the provider hosting the demo site, doesn’t support PEAR which I was using to access the database.  I needed to migrate to the WordPress database abstraction layer.  As opposed to just hacking up the plugin to do this, I decided to do it right and enhance phpHtmlLib with a new database abstraction layer specifically for WordPress.  I also made the changes to phpHtmlLib to make it into a WordPress plugin.

All in all, a lot of work behind the scenes which isn’t visible to the end user but in the long will make using wp-SwimTeam by other people much easier.  There are quite a few posts on my wp-SwimTeam development blog if you are interested in all of the nitty-gritty details along with my frustrations with GoDaddy Support.

UI Change for wp-SwimTeam

As the Swim Team Dashboard menu has grown I have been thinking of changing how I present the various choices to both the Admin as well as a Subscriber.  While I have thought about it from time to time, I haven’t done anything about it.  I was recently looking for something in the WordPress plugin directory and found something called Lighter Menus.

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.

Google Maps problem is fixed!

Last night I fixed the Google Maps problem by re-coding the way I was getting the data from Google.  I had been using a class called Phoogle but have eliminated it in favor of a direct AJAX solution using Google’s AJAX API.

Instead of embedding this new solution in the wp-SwimTeam plugin, I implemented as a widget in phpHtmlLib.  It works pretty well too!

phpHtmlLib is now a WordPress plugin

The overhaul of phpHtmlLib is largely complete, I just need to validate a few more things before I call it done.  One of the things I did during the overhaul was to add some things to the library so it will load as a WordPress plugin.  This will make installation and configutation much easier.  The changes to phpHtmlLib made the migration from PEAR to the WordPress database abstraction class much easier.

Significant change to the Database Class

Getting a demo up and running on a new host has been very enlightening.  I have used the PEAR DB class for years because it works well and is usually available.  The host which is being used for the demo site doesn’t appear to have the PEAR DB class installed so this has motivated me to migrate the SwimTeamDBI class to make use of the builtin WordPress database access class instead of depending on PEAR.  I have considered doing this for a while but have put it off but it looks like it is time to deal with it.

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.


I have been putting some cycles into phpHtmlLib as part of getting my wp-SwimTeam WordPress plugin in shape for other people to use it.  I found that PHP5 and GoDaddy’s PHP configuration, phpHtmlLib wasn’t very happy.  After a couple days work I have it put back together so it will work with both PHP4 and PHP5 and can deal with GoDaddy’s PHP configuration.  Now I need to commit all the changes and get back to work on wp-SwimTeam.

The trickle down effect

While trying to get a demo site up and running I ran into an issue that has taken me down a path I didn’t expect to head down at this time.  But now that I have run into it, I have decided to fix it correctly.

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.