Get it All

Took me basically all day to get this done, but as of this moment, is now powered by the newly-fused WordPress 3.0 installation. Whereas previous versions of WordPress were branched into WPMU and WordPress classic versions, the new version brings it all back together (very Holistic, actually!) into a single installation.

I’m going to confess that vanity made me resist this new version: WPMU was the advanced version of WordPress that made me feel cool. But given the way in which I generally use WordPress MU on this site, the new synthesized version of WordPress is probably a better choice anyway.

On a technical basis, one of the things that concerned me most was how the association between the various blogs would differ with this new installation and whether carefully-built plugins that deliver the front-page content would end up broken as a result of the upgrade. I’m not sure whether the new version introduces new methods of access, but certainly the old ways have been maintained and the transition has been fairly straight-forward as we’ve come to expect from the great folks at Automattic.

So the question now is: how does this affect my WordPress MU Function List? Are these functions still relevant and should I create an entirely different page for new stuff? I must confess that I’ve been out of the WordPress game and only just barely paying attention to the Hackers list, so perhaps tomorrow is a good day to correct that laziness on the WP front!

Another task for the near future is yet another redesign of the front page. My “Fluidity” experiment was a good one and worthwhile. But now that I’ve had a chance to see what the front page looks like on a high-resolution wide-screen monitor, it’s clear that the experiment should be brought to its swift conclusion. My blue and white pipes theme will doubtless be maintained, but I’d like to return to a fixed-width design. All in good time!!

This plugin is deprecated and no longer maintained by the developer.

The new 2.7 version of WordPress MU is pretty awesome and I’m glad to have it running on both of my sites right now. There’s a lot 2.7 has to offer in terms of usability boosts, and while I balked at the redesign when it first started, I have to confess that there is much to love about the new layout.

However, one thing that’s been nagging me is the new Admin Bar functionality. It suffers from two things, in my opinion:

  1. It’s a blog by blog setting, not sitewide. This is fine for sites where you want savvy people to start blogging on your network. It’s less so for community based sites like mine, where the idea is a sort of news magazine site where consistency is key.
  2. Because plugins can add their own top-level menus, the Admin Bar can get a bit crowded and I’d like the option to add or subtract items from the list as I see fit. Again, it would be nice to have these settings happen globally rather than by site.

While I have not worked out the second problem just yet, I thought I’d go ahead and post my modified code to this site which allows site-wide settings rather than by-site. It also tucks the Admin Bar settings under the Admin section rather than Options.

There’s nothing magical here: all I did was change every occurrence of “get_option” and “update_option” to “get_site_option” and “update_site_option.” Then, I just modified the menu statement to look like the following:
// Register the settings page
function AddAdminMenu() {
add_submenu_page('wpmu-admin.php', __('WordPress Admin Bar', 'wordpress-admin-bar'), __('Admin Bar', 'wordpress-admin-bar'), 'read', 'wordpress-admin-bar', array(&$this, 'SettingsPage') );

Download the file here and replace the one currently sitting in /wp-includes/wordpress-admin-bar/

Meanwhile, I’m going to work on tweaking the plugin to make it more flexible for MU as I go.

I’ve just upgraded to the latest Beta of WordPress MU, version 2.6. They’ve opted this go-round to keep the version numbers of WP and WPMU the same, which is probably for the best. No matter how you slice it, keeping the versions in some sense of organization is a challenge, keeping people from getting confused is a challenge, so you may as well go for as much transparency as possible.

But right now, I’m most concerned with whether or not the xmlrpc.php problem has been fixed. I’ve been struggling at my main blog with the lack of this functionality, which has become integral to how I perform certain mission-critical tasks. Version 1.6.1 had problems with this file. I’ve not seen anything on Trac that necessarily indicates that it’s been fixed, but I figured rather than comb through a bunch of stuff online, I’d just turn up the juice and see what shakes loose. Well, we shall see in a moment, when I hit “publish,” shan’t we?

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.

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!