A few weeks ago I was asked to perform the proverbial ‘impossible task’ by the director of my department. Granted, the director was no ‘pointy-haired-boss’ by any means; he had Unix and programming experience. But still, what he asked seemed herculean in nature, even for me. The task:
“Amin, I need for you to migrate all of the blog.usf.edu blog instances to a new Wordpress MU installation, and it NEEDS to be done by Friday.”
There were 600 independant wordpress blogs with two-year-old codebases on a old and decrepit webserver. This installation existed before Wordpress MU was the tried and true, so shell scripts generated a stock wordpress install whenever a user requested one via a login form. This version of wordpress was so old, I couldn’t just log in and export their blogs to XML and import them on the new system. I had to dump their database tables, manipulate their schemas using sed, import the data, generate mass SQL commands using /bin/bash foo.. This guide was pretty useful, but it didn’t take for account the old wordpress version.
PROTIP- Make sure that your post tables have a type called ‘post_type’, with default set to ‘post’. Older versions of wordpress didn’t have this, so I had to add the column to make MU read the posts).
Well anyway, after implementing a custom authentication plugin using LDAP, overriding some default features, and doing a bunch of MySQL ninjutsu, I managed to make a rather nice replacement for blog.usf.edu. You should check it out.
Anyway, after pulling that off, I apparently am now the local Wordpress guru. Really, all I did was read the above guide and some developer documentation and hacked my way through. Oh well, I can allow myself to bask in sysadmin glory every once in a while.