When I started using FireFox, I discovered something truly amazing (to me at least) in the development world: the idea of separating basic functionality from advanced usage; the idea that a program could be continually improved upon in terms of security and stability without having to add on new features and gadgets, and new gadgets could be added as desired without danger to the core application’s stability.  This was something foreign to someone accustomed to downloading the latest Microsoft updates, which always blend fixes with new features in a confusing and often problematic way.

And since working with WordPress, I’ve come to expect roughly the same thing of that platform.  Plugins can be added at will with minimal risk to the core, and the core updates periodically with new bug fixes and improvements to stability, security and performance.  That is, until 2.3 came out, then 2.5.  And perhaps more importantly, until the new development schedule came out.

WordPress 2.5 is a great new interface that improves the back end and allows us plugin developers to hack what is probably the most important bit of WordPress: the author/administrator interface.  WordPress 2.3 expanded the role of what they now refer to as “terms” and introduced tagging, which I have to admit I love.  But these are radical changes to the core with far-reaching consequences - and they piggy-backed each other in the space of maybe six months.  Its one thing to say that we developers need to keep up, but these changes drastically affect the end user experience in complex ways that are sure to leave them in the dust.

What’s more, they want the development process to be this fast.  Indeed, they skipped right over 2.4 because the changes they wanted were so radical that there wasn’t time in the release schedule to come up with a stable 2.4.  That should be some indication of just how completely crazy their schedule is.  But I haven’t seen a whole lot of talk about it.  Rather, the impetus coming from the top seems to be that WordPress needs to remain competitive and therefore has to have a fast-forward development schedule.  Their release schedule is even planned on a time-based scenario, rather than the more logical needs- or at least design-based schedule.

But now we’re stuck with a Microsoft-esque problem, in that in order to maintain the security and performance enhancements of WordPress, we must of needs also accept new feature enhancements which we may not want or need.  This is not what I’d expected of WordPress at all.

I realize that some changes need to affect the core directly.  I accept that software needs to advance itself in order to remain relevant.  But I am hoping that the folks who push the levers at Automattic rethink their insane release schedule.

It was with much anticipation and a fair amount of trepidation that I awoke this morning, prepared to upgrade WordPress MU to the new 1.3 version. The new version brings MU in line with the WordPress 2.3.1 codebase, including its new and complex “taxonomy” structure, while also implementing a bunch of MU-specific upgrades. I’ve been looking forward to working with the tagging concepts for a while, now, but upgrading MU is not an easy or entirely clean process.

Because unlike WordPress, you can’t just overwrite files from the old version. Well, you can occasionally, but in this instance, because there are a number of plugin files eliminated and other changes, it’s not recommended. Besides which, if you’re running an MU site with a number of users, you’re likely to find that upgrading in such a way that leaves the website open for a time comes with some complications that are probably best left avoided.

So, I can faithfully report that, if you delete all files and begin the upgrade with a clean MU installation, the upgrade actually is quite painless. I’d wondered if switching to the new taxonomy tables would make things complicated, but it doesn’t. In fact, Donncha was even nice enough to include a plugin for converting Categories to Tags site-wide, if you so chose. This all makes me feel pretty good about switching over on my main website as well.

On the other hand, there is a slight complication to switching over there which I’ve not worked out yet: the newest MU-specific addition in this release is the option to modify registration availability. You can now specify if visitors can create blogs, user accounts, or neither and you can also set it to allow only registered users to create blogs (which I presume means that visitors cannot create user accounts, otherwise that would defeat the purpose, as I’ve discovered. More on that later). This is a great addition which was desperately needed, as was the ability to hide your wp-signup.php file from search engines, thereby reducing the effectiveness of certain kinds of spam/splog attacks.

However, I’ve been using a tweak I’d developed which allowed users following a key-encoded link to create both the username and blog while providing other users only with the option to create a user name. It was a scheme meant to at least avoid spam somewhat while allowing my approved users to create the blogs they needed. It’s not100%, but it keeps the tourist spammers at bay for the most part and saves me the trouble of having to either a) create blogs for users or b) provide an extra set of instructions for creating the blog after they’ve created a username.

Well now, with this new change, all that goes away. I haven’t had the chance to check out the files that go into making this whole thing work, but I suspect my hack will not be able to live along-side the current system. In any event, I’ve also realized that my plan - cunning though it might at first have seemed - did not take into account the fact that registered users could create all the blogs they wanted. So, all someone with the time and drive would have to do was create a username and then create blogs all they wanted. Someone actually did this, though I suspect in this case that it was unintentional.

I think I’d rather have the security than the ease of administration, speaking personally, but it’s prohibitive for users starting up on my system. What I might do is edit the wpmu-functions.php to include a link back to the wp-signup.php file in the user account registration email, but I’m not sure. It figures that, after almost a month wrangling people into blogging on my network, people start suddenly all getting around to setting up their blogs on the weekend that I want to make this upgrade. This is one of those things that’s not really possible to do in a few minutes before I go to bed, so weekends are pretty much the only near-convenient time frame to do such upgrading.

Oh, yeah! And I’ll also need to upgrade my templates to include the new tagging features as well. Joy!