Switching from Movable Type to WordPress
Sunday, March 13th, 2005Downloading WordPress was much easier than downloading Movable Type. Installing WordPress was very easy. Importing from Movable Type was also easy, unless you include the hours I spent cleaning up WordPress's mistakes in the import process (see "Problems I ran into after importing from Movable Type" below).
I found that WordPress could be installed in a directory with generated Movable Type content. Apache chooses the index.html generated by Movable Type over the index.php that is part of WordPress, so the Movable Type blog was still live until I deleted index.html. This approach worked better than installing WordPress in a different directory, which was the first approach I tried.
Advantages of WordPress over Movable Type
- WordPress is free and will remain free.
- When I am logged in, I get an "Edit" link for every post and comment. With Movable Type, I had added a <link rel="edit"> to every individual archive page and written a bookmarklet to follow these hidden links. WordPress's "edit" links are built-in and more convenient.
- Templates are arranged in a way that avoids duplication. I can change the sidebar in all pages from sidebar.php, and a single edit modifies how posts appear in both category archives and monthly archives. (I had rearranged my Movable Type templates in a similar way.)
- No rebuilds. Rebuilds in Movable Type were slow, and I had to to think about what needed rebuilding after each change.
- The default template, Kubrick, is prettier than Movable Type's default template.
- WordPress automatically adds rel="nofollow" to every link added by commenters or trackbacks. This might be enough to keep spammers from actively seeking out WordPress 1.5 blogs to spam.
- Trackbacks and comments are combined.
- Permalinks for comments.
- For each post, there is an RSS feed for comments.
- RSS feeds for many pages. For URLs that start with "/index.php?", such as searches, change "/index.php?" to "/feed?" to get an RSS feed. For other URLs, such as category archives, simply add "/feed" to the end. If you prefer Atom to RSS, use "/feed/atom" instead of "/feed". I haven't added links to these RSS feeds yet. (With Movable Type, I had set up category feeds by adding a new template.)
- Cruft-free post URLs. (When I enable this feature, I had to paste rules generated by WordPress into an .htaccess file. For some reason, WordPress does not have permission to edit my .htaccess files on its own.)
Disadvantages of WordPress
- WordPress generates every page for every request, so loading my blog is now slightly slower.
- WordPress doesn't support If-Modified-Since, so every request results in an entire page being sent, even if the visitor has a cached copy and the page hasn't changed. When I used Movable Type (which does support If-Modified-Since), RSS feeds accounted for over 10 GB/mo. I'll have to keep an eye on my bandwidth usage for a few days. I don't know what percent of RSS readers requesting my feeds support If-Modified-Since, so I don't have a good prediction of how much bandwidth my RSS feeds will use now. I'll probably be ok, since I was only using 25 GB/mo of DreamHost's generous allotment of 120 GB/mo.
- Kubrick (the default WordPress theme) uses images in bad ways. For example, there is a single background image for the content area and sidebar combined. Also, the backgrounds don't seem to have corresponding background colors, so the background colors are very wrong until the background images load.
- Kubrick is too narrow for The Burning Edge because you can't see enough bugs at a time. This will take some work to fix.
- Kubrick uses some some CSS rules that use "ol li" where they should use "ol > li". "ol li" matches a list item in an unordered list that is nested in an ordered list, such as in this post. I think I can fix this without breaking Internet Explorer.
- Kubrick's CSS doesn't take into account the different element classes on the main page and individual archive pages, so paragraphs and lists in posts look different depending on what page you're on.
Problems I ran into after importing from Movable Type
- Character encoding. My Movable Type content was exported as ISO-8859-1. WordPress imported this file as if it were UTF-8. As a result, many western european characters in my posts got mangled and I had to fix them manually. I later read that some switchers avoided this problem by converting the file from ISO-8859-1 to UTF-8 using a text editor before importing. Characters not in ISO-8859-1 had already been converted to numeric HTML entities(?), so they were fine.
- Post formatting. Movable Type has two methods of formatting posts: "None", which leaves your post alone, and "Convert line breaks", which converts double line breaks to paragraphs and leaves single line breaks alone. WordPress's import script doesn't pay pay attention to which Movable Type formatting method I used, and it doesn't have modes correpsonding to either of Movable Type's modes. WordPress has more complex formatting: "Correct invalidly nested XHTML automatically", auto-formatting, and auto-texturizing(?). All three of these features are so buggy that I had to disable them.
- "Correct invalidly nested XHTML automatically" doesn't let me nest blockquotes, and actually changed the original HTML for one post that uses nested blockquotes. It was easy to turn off.
- Auto-formatting added <br /> tags for every line break and put <p> tags in many places they didn't belong, such as inside <textarea> tags. It also inexplicably added backslashes before double-quotes within <pre> blocks in this post and this post. I had to install the Text Control plugin to disable it.
- Auto-texturizing, which turns quotes into “smart” quotes. It got the direction of quotes wrong in this post. It also smartified quotes in places they shouldn't have been smartified, such as in examples of HTML code and examples of Google queries. The Text Control plugin let me disable this feature too.
Before I tried turning off auto-formatting altogether, I tried using Markdown instead of WordPress's default auto-formatter. Markdown fixed some of the problems, but not all of them, and introduced some new (minor) problems. I ended up disabling it too.
Once I had disabled auto-formatting, I was left with the problem that many of my posts didn't have <p> tags, because I had relied on the "Convert line breaks" option in MT. I wrote a bookmarklet to add those tags to posts that needed them. (Note: this bookmarklet doesn't handle <!--more--> well.)
- Headers in posts. In my modified Movable Type template, posts were <H2>, so sections of posts were <H3>. In Kubrick, posts are <H3>, so sections of posts should be <H4>. I made this change manually in old posts. This change should make Planet happier too.
- Home page title. I wanted the front page of The Burning Edge to have the title "The Burning Edge - Firefox nightly build changelog" rather than just "The Burning Edge" to help search engines and search engine visitors. My solution was to add a PHP conditional statement using is_home() to the part of header.php that generates the <title> tag.
- Redirecting individual archives. I wanted to redirect old Movable Type URLs to new WordPress URLs because many people have linked to the old URLs. I used a modified version of this Movable Type template to generate .htaccess redirect rules. I had to add encode_php="qq" and str_replace("_", "-", ...) in order to make my URLs correct.
- Redirecting other URLs. I redirected what I thought were the most important category, RSS, and category RSS URLs manually by adding .htaccess files. I'll go through my error logs in a few days to see what other URLs need redirecting.
