I’d been holding off on upgrading to WPMU version 1.5.1 because I was worried that the extent of the changes from 1.3 to the new 2.5 codebase might be a bit too much for the system without some serious recoding.  Turns out, I was about half right.  And when I did finally upgrade about a week ago, it was a comedy of errors that forced my hand.

Since I’m on a web host that limits the size of my database, it has ever been a concern that I would hit the cap on my main blog.  The Tan-Tan Noodles Flickr Plugin did just that to me, since it saves all the pictures you display with the plugin as binaries in the database.  Suddenly one day, I could not post to my site and plugins seemed to be magically turning themselves off.  I thought for sure that someone had hacked into my site.

So, I opted to upgrade, hoping any security holes in 1.3 might be closed in 1.5.1.  Crazy, but again, I was panicking with a fairly high-traffic site suddenly being in limbo.  Unfortunately, I didn’t figure out the db problem till long after I’d already overwritten my old 1.3 files.  After I did the upgrade I found that my templates weren’t loading correctly.  Why should that be?

It turns out, after a long time troubleshooting, that a couple mu-plugins I’d written to bring content from other blogs to the main blog had become unusable.  I figured this out because Donncha’s post describing some of the new changes mentioned that plugins using the switch_to_blog() method might have a problem with the new caching system.  That didn’t turn out to be the problem, but since some of my code was still using another method of snagging the info (literally, concatinating “wp_1_posts” and querying the db directly!), it was this method that was causing the problem.

So a warning to you plugin writers out there: stick to the WPMU API to the best of your abilities!  I’m not entirely sure why querying the db would have caused so much grief, but when I switched to the API, I had no problems.

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.

I’ve just completed a new plugin, called the Titles to Tags plugin, which I’m sorta proud of. Basically, it checks the title of your post against a list of ignorable words, and then adds tags to your post automatically out of those words that did not appear on the ignore list. The idea is to automatically create a list of relevant keyword tags for your posts. The nice thing is: since I’ve learned to adopt the WordPress API, I’ve found that writing plugins often becomes a much less complex process.

For example, in this plugin, I have to add tags to a post. Obviously, I don’t want to create duplicate tags or create them incorrectly. The new tagging schema is quite complex in the database, and I don’t recommend anyone bother trying to create new tags directly. Instead, I used the wp_add_post_tags() function. This function first checks the current list of tags for the ones I want to add, then if none exist, it creates the tag automatically. This kills both birds with a single stone.

Plus, of course, if the underlying structure of WP should change - and we know it will, eventually - the API will either remain the same or be kept as vestigial, so the plugin doesn’t break because a blog owner did the responsible thing and upgraded to the current version. Another major advantage is that WordPress functions often go through rigorous standards testing and benchmarking, so by using API functions, you’re getting your best shot at creating a highly-compatible and optimized plugin.

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!