Recently I reviewed my old posts at the Wordpress-mu forums and realized that there was some activity on those posts that I hadn’t noticed. It became clear that the plugin needed some modification and also that it only supported per-blog registrations for Wordpress-mu installs based on subdomains, but didn’t work for installs based on subdirectories.

This past weekend I took another look at the plugin and found that most of the inconsistencies I had been seeing, and for which I had tried to code around in the plugin, were gone in v1.5.1, and so I was able to remove the vast majority of the plugin’s code.

The current plugin seems to work for both subdomain-based and subdirectory-based installs, at least on a fresh install of Wordpress-mu that I was working with.

Update [Mon Aug 17 14:02:16 EDT 2009]: http://code.creativecommons.org/issues/issue436.

I admit that going into the evaluation, I was predisposed to like Lyceum. This predisposition, like so many, was based on completely irrelevant facts: I like the way their website looks, I dislike the wordpress.org forums[1], that sort of thing. And initially it looked like Lyceum was going to be the winner. Both their website and the Wikipedia article on Lyceum[2] stated that a difference between MU and Lyceum was MU’s requirement that every user have their own blog. That was clearly a deal breaker for us: we needed multiple multi-user blogs, not multiple single user blogs (and we didn’t want a pile of single-user blogs lying around as a side effect of implementing the multi-user blogs). However, after installing MU and poking at it a bit, this doesn’t seem to be the case any longer.

The primary difference really comes down to how they handle the database tables. WordPress MU creates a separate set of tables for every blog. Lyceum modifies the basic WordPress table structure to add blog information to the tables. And there seems to be some debate over which is more efficient and scalable: tons of rows, or tons of tables. In the end, I’m not smart enough (or maybe I just don’t care enough) to evaluate which statement is truer. We chose WordPress MU for a couple reasons:

* Wordpress.com uses it, so it’s *at least* scalable enough for an installation of that size (which we won’t even approach).
* It appears that some of the core WordPress developers work on it, and it shares much of the same table schema information with WordPress. This leads me believe that it will track the core WordPress development closer.

So in the end, it came down to a gut feeling more than anything else. I suppose this is the best sort of evaluation you could ask for: one where you have two great pieces of software, and it really comes down to these intangibles. It certainly speaks well of the open source community, and the WordPress core in particular.

fn1. More than I dislike most forums, which is saying something.

fn2. Since edited.

The bug was simple: the documentation says that the licenseUri function returns the URI of the selected license. And that’s what the internal wpLicense code relied on. However, the implementation actually echo‘d the URI, introducing a race condition: if things were timed just right, the problem wasn’t apparent. But too often they weren’t, and then it was.

There are some outstanding issues with wpLicense, particularly with rendering the selection interface under Internet Explorer. That’s just one of the tasks new web engineer will be tackling when he or she comes on board. Which reminds me, we’re still accepting resumes.