WordPress multisite

I just switched to a new server and found myself struggling with empty HTTP headers and broken or partial images. The problem is the memcache extension for PHP and WordPress MU/WordPress multisite’s need to reinstantiate the wp-cache after determining the correct blog for a given request.

Versions of the memcache extension prior to 3.0 go wrong somehow and it shows up when you try to do an HTTP HEAD request on a page (the result is empty) or enable X-SendFile support for WP MU/MS’ file handling (all the files and images in the media library will break). Upgrading to the the 3.x version (in beta since 2007) fixes the problem.

You may have to uninstall the old version before installing the beta, and installing the beta via PECL requires adding “-beta” to the package name. Here are the commands:

pecl uninstall memcache
pecl install memcache-beta

I’ve been running a few instances of WordPress MU for a while now, so I was more than a little anxious about the merge of the MU functionality into the core of WordPress. It’s a good thing, but sometimes such dramatic changes pose rocky challenges.

Not so in this case.

Pete Mall blogged about it in May, and I’m happy to say that I followed those instructions (summary: upgrade, it will work) to upgrade both this site and Scriblio.net recently. The biggest challenge I faced was in migrating my SVN checkout (not discussed in Pete’s post, but people who install via FTP or use the auto upgrader don’t need to worry about this), and Pete noted the only gotcha that I might have encountered: changing the .htaccess to use a different file that had been used in WPMU.

I tested the migration on this site, and it rocked so much that I decided to go forward with upgrading the other site, even though WP3.0 hasn’t been formally released yet. Rock n roll.

A few lines of SQL I used to clean up a Scriblio site. It’s probably useless to anybody but me. I’m not suggesting anybody else use this code, as it will result in changed or deleted data.

Update the post author for catalog records (identified because they have a specific post meta entry):

UPDATE wp_8_postmeta
JOIN wp_8_posts ON wp_8_posts.ID = wp_8_postmeta.post_id
SET post_author = 15
WHERE meta_key = 'scrib_meditor_content'

Get the categories attached to every catalog record (except the “catalog” category):

SELECT tr.object_id , tr.term_taxonomy_id
FROM wp_8_term_relationships tr
JOIN wp_8_posts p ON p.ID = tr.object_id
WHERE tr.term_taxonomy_id IN (
	SELECT term_taxonomy_id
	FROM wp_8_term_taxonomy
	WHERE taxonomy = "category"
	AND term_id != 30
)
AND post_author = 15
ORDER BY tr.object_id , tr.term_taxonomy_id

Using the above list of object ids and term taxonomy ids, build a series of queries like the following to delete them:

DELETE FROM wp_8_term_relationships WHERE object_id = 12275 AND term_taxonomy_id = 271872 ;

Insert a catalog category relationship for all catalog records:

INSERT INTO wp_8_term_relationships
SELECT p.ID , '271871' , '0'
FROM wp_8_posts p
LEFT JOIN wp_8_term_relationships tr ON p.ID = tr.object_id AND tr.term_taxonomy_id = 271871
WHERE post_author = 15
AND tr.term_taxonomy_id IS NULL

You’ve got to both respect Automattic for releasing their internal code as open source while also giving them a break for not assuring that it works for anybody else. One of their projects, the WordPress.com Video Server is a sophisticated WordPress plugin that handles video transcoding and offers a bit of a YouTube in a box solution for WordPress.

The bug I found is that the code assumes WPMU is running in subdomain mode, rather than subdirectory mode. This assumption causes an ajax request to go to the wrong URL and return the wrong data. The patch simply applies WordPress’ plugins_url() function that debuted in 2.6.

The BuddyPress forums have a number of threads about handling invitations (two worth looking at: one, two), but no real solution has emerged. At the same time, there’s also a need for some means of confirming other actions such as password resets, email changes (both of those are already handled by WPMU, I know), cell phone numbers to receive SMS messages, and other actions that need to be confirmed later.

So I’m proposing a generic API to handle things like this. The built-in WordPress cron and ajax functions seem to offer a clear pattern for creating such an API: Simply, plugins and core code could register an action and a function to be called when that action is executed. The API could also store data to be sent to that function when it is executed.

Among the things I’d do with this?

• Confirm email addresses
• Confirm cell phone numbers via text message
• Confirm IM accounts
• Confirm Twitter accounts
• Confirm password reset requests
• Confirm invitations in BuddyPress

Anybody else interested?

Sure, Matt says it’s Thank a Plugin Developer Day, but let’s hear it for the developers who just tagged WordPress MU 2.7! Not long ago there were still 300 files to merge, now it’s done and ready for the next version.

The news about BuddyPress has fully shifted my attention from single-blog WordPress installs to multi-user, multi-blog installs.

WordPress mu is my platform of choice, but I was quite fond of Lyceum when I first learned of it a while ago. The big perceived advantage of Lyceum is that it uses a unified table structure for all blogs, rather than creating a new set of tables for each blog as WPmu does. I’m not so sure that’s important now, and WPmu’s scheme now looks a lot easier to partition onto multiple database servers, should traffic ever scale there. Still Lyceum is an interesting project, and their name and logo are great.

Facebook and MySpace are trying to turn themselves into application platforms (how else will they monetize their audience?). Google is pushing OpenSocial to compete with it. But no matter what features they offer their users, they user still orbits the site.

Scot Hacker talks of BuddyPress changing the game, turning “social networks” from destination websites, to features you’ll find on every website. And the “social network” is the internet, with all those sites sharing information meaningfully.

Some might say this is little more than overgrown XFN, but Tris Hussey thinks Ning is on the ropes and Facebook should be worried.

At least the design shows all the right stuff.