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 otherblogs 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:

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:

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:

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.