Welcome to my new look blog. Oooh, shiny.
I’ve been trying to upgrade the software behind this blog on and off for quite a few years now. It was back in 2008 that I installed MovableType 4.12, and although MovableType has served me well I’ve been struggling to keep it maintained – for example, my custom templates were a bit broken, and the spam handling wasn’t nearly as effective as I wanted.
It’s taken a few days of beating up the server, but WordPress is finally installed. I’m still working out a few kinks, but for the most part everything is now in place. In case anyone else is looking to migrate, here’s the gory details on the incredibly painful process I had to go through.
The first thing I did was made sure my server was running the latest version of Ubuntu, 11.10. This turned out to be a slight mistake – and I lost some time to fixing a logging regression. Latest and greatest is not always best, especially when you’re on a virtual server.
I made sure my MovableType data was as good as it could be. I cleared out any draft articles that were hanging around, and I dealt with in excess of 1200 spam comments. The final tidied- up data includes almost 1400 blog posts and over 800 comments – accumulated over more than eight years of writing.
I opted to install WordPress from the Ubuntu wordpress package, as one of the reasons my MovableType install got so old was because it was a manual install from source packages.
A couple of tips:
- I did the initial deploy on my test domain, and kept refining it until I was happy. I thoroughly recommend this approach, as otherwise you could be looking at sleepless nights and days with your blog out of action. There is some pain in the final switch over to the live domain, but it’s worth it.
- It took several attempts to find the right solution in terms of configuration and data import mechanism. It was therefore useful to reset the WordPress installation each time by running /usr/share/doc/wordpress/examples/setup-mysql with the -d flag (for ‘destroy and purge’), to get back to a vanilla state before trying again.
The final process was then something like:
- From a clean vanilla install, I went through the initial WordPress configuration: running setup-mysql specifying the database name and the website domain, then visiting the website and going through the long and tedious setup (uh, entering a username and password – crazy simple!).
- I downloaded, installed and enabled the bulk delete plugin to let me get rid of posts when I got the imports wrong.
- I deleted the default first post that WordPress automatically creates.
- Trial and error proved that the WordPress-provided movabletype and typepad importer is useless. It only imports the bare minimum of data. The movabletype backup importer is far more complete, so I installed that.
- I created a backup of all my MovableType blogs from the MovableType web interface (top-right System Overview menu, Tools, Backup). I chose .tar.gz archive format, and set the Target File Size to 300KB to make debugging broken exports a little easier. The backup should be unarchived into the wp-uploads/domainname/import folder.
- It turns out the MovableType export does not always correctly encode all entities, and this broke the import. It also transpired that most recent moderated comments had an incorrectly set junk status. I wrote a fix_export.sh script to fix both these problems. I then ran the fix script on my data prior to triggering the import.
- Through the backup importer plugin screen, start the import. You might want to keep an eye on your webserver error logs for any failures, as the importer doesn’t report back errors.
- Once the import was complete, I updated the database manually to tidy up comments, specifically replacing ‘Registered User’ with my real name: update wp_comments set comment_author=’Andrew Savory’ where comment_author_email=’the email address I used’;
- The next challenge was to fix WordPress’ ugly URL scheme. By default, every post hangs off the index page with the post ID as a query parameter. I decided to go for a year prefix followed by the post ID.
- The biggest problem with the migration is that the URLs for MovableType and WordPress are completely different. Lots has been written about clever ways to fix this: Using Permalinks, MovableType to WordPress without losing your permalinks, From MovableType to WordPress in 301 Easy Steps, and so on. But there’s no guarantee post IDs will be the same across the two blogs, so the simplest solution seemed to be to write a map.pl script to create rewrite rules to handle this. See Apache Module mod_rewrite and Redirect Directive for more information. The output of the mapping script was 1876 lines, so I kept it in a separate file and used the Include directive to import it into my webserver config.
- I added a few manual redirects for the various old RSS feed URLs to point them to the new URLs. See WordPress Feeds and Customizing Feeds for more information on the feeds available.
- I then changed the default about page, and then fixed the configured WordPress blog address and site address in the general settings. This also involved some renaming (for example the config file in /etc/wordpress).
- Finally, once the blog was at the correct address, I updated the header to suit the season, went mad adding a ton of plugins and tweaking widgets. In particular I added Google Analytics (no more manual editing of MovableType templates to make it work!), and did some work to ensure scaling and caching: see also WordPress Optimization/Caching.
There were a few teething troubles – when I first put the new blog live, WordPress decided to screw up the URL scheme, for example. Some of the plugins are still distinctly unhappy. There’s still a few broken images on the earlier posts, as I was inconsistent in whether I used flickr, uploaded images to the blog, or just copied them onto the server. Some of the posts have technorati tags in the body rather than in the metadata. Some of the mobile blog posts are badly-formatted and show up CSS in previews. I’m slowly working through all those problem posts and fixing them.
Hopefully readers will find the new look easier on the eye, with better access to the content. Happily, all the old links should still work, too. I’m looking forward to blogging without the nagging sense that I’m dumping content into an old legacy system. And to playing around with more plugins. Shiny!
Forgot to mention – one critical principle during this move was the notion that “cool URIs don’t change” … so I wanted all my old links to work.
I was less worried about all the bandwidth leeches who linked to images from my site, and the raft of random 404s in my server logs seem to suggest that was a good idea.