Moving to Movabletype from Radio

I decided to move to Movabletype from Radio. Here's why and how I did it.

My reasons for switching from Radio were many. I was quite happy with it back in the day, when I thought it was going somewhere, but lately its seemed stagnent. Add to that daily frustrations with the Radio client on OS X and I finally decided to make the switch. It wasn't easy, which is why I'd been putting it off so long.

My reasons for switching to Movabletype were pretty simple. I'd been using it for other blogs for over a year and liked it. There's good support and a community of tool builders. Furthermore, its written in Perl and I'm a Perl hacker.

Moving the Data From Radio to Movabletype

The first job was to get everything out of Radio and into Movabletype. I explored a number of paths and ultimately decided that Bill Kearney's Radio Exporter tool was the one I liked best. Naturally, it didn't work with Radio on the Mac and just crashed. So, I transfered everything to Windows machine (this isn't hard--just transfer the files to the Radio Userland directory on the Windows machine) and did the export there. Don't check the XMLify button since this encodes all the HTML and that's probably not what you want. All in all, I transfered 1550 entries.

Movabletype import doesn't delete the eight dash (--------) separator that it requires between bodies, so I had to remove it using a SQL command on the raw Movabletype database. (Don't try this at home since you can seriously mess up any other blogs hosted on the Movabletype installation if you don't get it right.) Here's the command I used:

update mt_entry set entry_text=substring(entry_text,1,length(entry_text)-8)
where entry_blog_id='11';

Note that the entry_blog_id is the id number of the weblog. You can see it in the URL of Movabletype when its editing a blog. If you get that wrong, you'll delete the last eight characters of every entry of some other blog on the server. This is non-recoverable it you make a mistake, so if you're unsure of what you're doing back up the database first.

You'll want to import the entries to a new Movabletype weblog before any customization if you can. Then when you screw it up, you can just delete the blog and start over. Make sure all the entries are imported exactly how you want them before you do a lot of work creating templates and so on.

Maintaining Permalinks

I tried to make sure that as many URLs remained unchanged as possible. This isn't easy and perfection probably is impossible. One of the first things it to make sure the name of date based-archives is the same. Use this as the file format for the date-based archive:

<$MTArchiveDate format="%Y/%m/%d.html"$>

One of the things I wanted to do was move to an server-side include architecture because it reduces the number of file rebuilds when the site style is updated and, more importantly, keeps the sidebar content fresh on even the oldest entries. For most things this is sufficient and the dynamic page feature is overkill. Since preserving URLs was important, I had a few choices:

• Make html the extension that triggers the server side include.
• Use URL rewriting to rewrite and html URLs on the site to shtml.

Since I was going to need mod_rewrite for other things anyway, I chose the latter. Here are the rewrites I made:

    # handle categories
    RewriteRule   ^/categories/.*/(20../../..)\.html$   $1 [C]
    RewriteRule   ^(.*)$ /archives/$1.html

    # handle old archives
    RewriteRule	  ^/(200[2|3|4].*)$	$1 [C]
    RewriteRule   ^(.*)$ /archives/$1      		   

    # rewrite html as shtml and redirect
    RewriteRule   ^(.*)\.html$              $1      [C]
    RewriteRule   ^(.*)$ $1.shtml                   [R]

Here's what they do in English:

• Rewrite any category day archives to the plain archive. This was easier than trying to make Movabletype generate day archives in each category and probably just as well. Not many people go to those and this gets them what they were after, possibly mixed in with a few things not in that category.
• Rewrite any date archives in the root directory to the archives directory. I could have changed Movabletype to put them in the same place Radio did, but I like to stick with the standard if I can and I was rewriting anyway.
• Finally, rewrite .html to .shtml. This means that I can't use plain .html file extensions anywhere in this blog. That's probably OK. If not, I could get fancier and only rewrite if the .html file doesn't exist. The [R] flag causes a redirect or else the .shtml won't trigger the server-side includes.

There's one more problem with categories. Radio makes a category directory name (i.e. dirifies it) by removing whitespace, capitalizing all the words except the first which is all lowercase. So, "IT and Society" becomes a category directory called "itAndSociety." Movabletype's stock dirify algorithm lowercases everything and replaces whitespace with underscores, so that same category is rendered as "it_and_society." I found a nifty Movabletype plug-in called DirifyPlus that almost does what I want. With it, I can produce category names that look like "ItAndSociety." Close, but not close enough.

I solved this problem by adding a new case to the DirifyPlus plugin to emulate Radio behavior:

elsif ($b eq "r")            ## radio style
    {
    $s =  lc $s;                ## lower-case.
    $s =~ s!(\b.)!\U$1!g;       ## captialize words
    $s = lcfirst($s);
    }

Then, I used this template for the category archive file:

<$MTCategoryLabel dirifyplus="prn" $>/index.shtml

The last thing to do for categories was to create per category RSS feeds. Its not that I'm convinced that a lot of people subscribe to the RSS feeds in individual categories (although I checked, and some do), but I find them useful for producing special purpose RSS feeds. That's the way my newsletter is produced, for example.

To create per-category RSS feeds, I largely followed these instructions modifying the RSS 2.0 template as appropiate and using a template like the one above for the filename, but naming it rss.xml instead.

Since Radio doesn't create individual archives (one per item), it uses page anchors in the permalinks. These present a problem. The anchor is based on the entry ID number in Radio. Movabletype uses the same strategy. Theoretically, if you were installing to a fresh Movabletype installation (no other blogs) and you'd never deleted any post in Radio, these would match up. I was out of luck in both cases. I tried various strategies to make them match, but since they're not exported from Radio and not imported to Movabletype, its hard to do. The problem with page anchors is that they're purely a client side thing--the server never sees them--so you can't rewrite them on the fly. You've got to generate the pages with the correct anchors. I finally gave up. On average, I've done two posts per days, so the permalink will take people to the right page and they'll have two posts to choose from.

Setting Up Movabletype

The next task was to change the default templates. I like a three column blog and I like it reflected in the daily, individual, and category archives. To do that I create new templates in Movabletype as follows:

• links.inc - the right hand side content
• nav.inc - the left hand side content
• banner.inc - the banner

Then I modify the Master Index and archive templates to include these as server side includes. That way, updating any one of these is seen globally on the entire site. This also requires some style-sheet changes to make it all work. I'm no CSS expert, so I'm sure I've kludged it horribly, but it's working, for the most part.

I updated the meta information in the pages. I also made sure the the RSS feed was stored in rss.xml instead of Movabletype's standard location since that's where people who've subscribed to my feed expect to find it.

Movabletype uses a global search template that loads /style-site.css, so you get the right colors and fonts (as long as you don't change the style-sheet location) but you don't get any other content, like my include files. Fortunately, there's a way to change this but you can't do it through the UI. Note that if you follow these instructions, you need to also modify the search box in the template to use the new template.

While changing the template went pretty much according to plan, I did have to play some games to make my include strategy work. Since the default search runs in the Movabletype home directory, it changes the base URL of the search page to where ever you loaded Movabletype. That broke any relative URLs in included files. In any event, I didn't like the URL changing. Fortunately, you can move the mt-search.cgi file to somewhere else and as long as it can find the mt.cfg file, you're golden.

Moving Other Writings

I've written a number of essays and so on that I used Radio's auto-upload and format feature. These all had to be turned into my new format. I use server side includes to apply a global template to a file that just contains the body of the document so that I can easily update it later and have all the styles change as well. Naturally, this too uses the include files I've created in Movabletype for the left-hand navigation and banner. I used a similar strategy to store the few stories I'd posted in Radio in the new format.

I also had a bunch of stuff that I'd generated as OPML in Radio's outliner. I used an OPML to HTML XSLT file that I modified from Bill Humphries. I just used a for loop in the shell on a wget call to the W3C's XSLT service to generate all the HTML files from the OPML. The result ended up being reasonably easy to edit and whip into shape.

Backups

One of the things I liked about Radio was that since it kept the database of entries on my local machine, my local backup regimine backed-up my blog as well. The server I run Movabletype on has a RAID 1 configuration so that the disks are mirrored, but that doesn't protect me from stupidity or maliciousness. So, I set up a crontab on my laptop (OS X) to run the following shell script once per day:

DAY=`date +%a`
BACKUP_DIR='/Users/pjw/Archive/mt_backups'
HOST='your_hostname_here'
MT_USER='your_user_name_here'
MT_PASSWD='your_passwd_here'

ssh $HOST "mysqldump -h localhost -u $MT_USER -p$MT_PASSWD mt"  \
   > $BACKUP_DIR/$HOST-MT-backup-$DAY.dump

This stores a dump of the Movabletype database (about 5M with everything, including UtahPolitics.org) on my local machine. The date +%a part of the file name ensures that I'll always have at most 7 copies of the backup. If something happens and I don't notice for a week, I'm hosed. Even so, this seems like a good compormise.

Summary

The move took about three days of pretty solid effort. There is lots to do in moving a blog that's as big as mine has become, but it is doable. The hardest part is keeping permalinks working. If you've got specific questions about details of what I did, feel free to write.

Last Modified: Saturday, 01-Jan-2005 22:17:15 UTC