Over the last couple of days I have been playing around with WordPress MU (aka WPMU), the multi-user, mult-blog version of WordPress. It has been on my “to checkout” list for a while but I haven’t had a compelling reason to do so until now.
I was asked to help set up some blogs for a group of soccer teams that are traveling to Europe later this year after doing one for my daughter’s team (one of the teams). This seemed like a good opportunity to try out WPMU since I’d also like to do it for my wp-SwimTeam plugin and make it available to swim teams as a hosted service.
Downloading and installing WPMU was pretty straight forward but getting it to work with sub-domain mode blogs turned out to be a challenge. I have concluded that without the ability to edit the httpd.conf file, it isn’t possible to make it work. I did manage to get the sub-directory mode working but that isn’t what I need for the soccer team project.
So for now, I am going to abandon WPMU and set up a series of regular WordPress blogs, one for each team. I am also looking at wp-Hive to help with this.
Over the last two evenings I have created my first real theme. I based on it on Sandbox and called it Sandbox-Soccer. It is a three column theme with two sidebars on the right hand side.
My daughter is playing on a travel soccer team which is going to Sweden later this year and their coach would like to chronicle the team’s activities leading up to and including the trip and he asked me if I could set up a web site for them. I used his requests as a compelling reason to get off my butt and design a theme.
Since I have little design expertise, I found some soccer related vector art on Wikimedia Commons and purchased some from iStockPhoto. It is amazing how much art is available for free (Wikimedia Commons) and for a very reasonable price (iStockPhoto).
With my art in hand, I started working in Illustrator to come up with something I liked. I had found the Watch Football Soccer WordPress theme a while back and I like the look and even downloaded and installed it. However, like a lot of free themes, it has some encrypted PHP code in the footer that does something. I dug through some of it and it adds links to things I don’t want to link to but some of it I couldn’t get decrypted enough to figure out what it did. Regardless, it was enough to concern me about using it so while I like the look, I didn’t like the implementation.
It turns out the artwork used in that theme is available from iStockPhoto. There are also several other variations. I like the silhouettes and found a collection of female soccer silhouettes (important for a girls team) created my own header graphic in a red/yellow/orange color scheme.
At this point it is usable but I will continue to tweak it too. There are some CSS bugs still in it which I need to fix. I also plan to do multiple color variations of it and have both male and female header graphics. I’d like to set up the color and gender choices on a theme options page.
The demo is running on my Theme Demo page. I will make a download available soon.
Before I know it swim team season will be here again and it has been a while since I worked on the plugin. Uh-oh. This fall has been busy, busy, busy with other stuff and I put the plugin development on the back burner for a while.
Since I last worked on the plugin, WordPress 2.7 has been released. WordPress 2.7 is so much better than any of the prior releases, going forward I expect it will be a requirement to continue to use the plugin. The Dashboard integration will be much more elegant if I require 2.7.
Look for some new updates in the very near future.
Running WordPress under SourceForge project web hosting service can be frustrating. It just doesn’t work as seamlessly as it WordPress normally does. When I first installed WordPress, the Akismet anti-spam plugin wouldn’t work (still doesn’t) because SourceForge doesn’t allow remote connections. Yesterday I wanted to include an image in a post only to find that I couldn’t upload an image due to a permissions problem.
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.
If you haven’t seen it yet, WordPress 2.7 changes the Admin interface again. While it seems many people don’t care for it, I like it a lot better than the existing interface. I don’t care for the terminology they used for the main headers on the side bar though.
I was on the road this week so spent some airplane time working on my wp-SwimTeam plugin and decided to see how it would work under WordPress 2.7. I have actually started moving my development around a bit and I think it will turn out to be a good thing. Yesterday and today I was running 2.7 under Linux with PHP 4.4.9. Last week I was running under Windows with PHP 5.2.6.
2.7 exposed a few things in my plugin which I have fixed but like I said, I am not happy with the new terminology being used. I had changed my implementation recently so the end user chose the Swim Team menu off the Users menu in the Dashboard and the Admin would choose Swim Team from the Manage menu. In 2.7, the Users menu doesn’t exist so there isn’t a logical place to put the functionality exposed to the end users. I’ll figure something out, in the meantime, there is plenty of work to do on the plugin itself.
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.
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.
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.
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.