Movable Type to WordPress, Part 2
February 6, 2008 at 11:13 PM by Dr. Drang
As the title indicates, this is another post on how I moved this blog from MovableType to WordPress. The first post in the series gave my reasons for making the move. This one will get into the move itself.
Local installation
My first step was to set up a local version of WordPress running on my iBook G4. I wanted the blog to have as little downtime as possible, and I wanted to work out the bugs on a computer I had full control over. Installing WordPress is supposed to be dead simple, and I suppose it would have been if I hadn’t run into problems connecting to the database.
I had MySQL installed and running, using the Hivelogic instructions. So getting WordPress started should have been a simple matter of editing a configuration file and pointing my browser to a particular local URL.
Here’s the configuration file, wp-config-sample.php, that you edit and rename before trying to start up WordPress:
1: <?php
2: // ** MySQL settings ** //
3: define('DB_NAME', 'putyourdbnamehere'); // The name of the database
4: define('DB_USER', 'usernamehere'); // Your MySQL username
5: define('DB_PASSWORD', 'yourpasswordhere'); // ...and password
6: define('DB_HOST', 'localhost'); // 99% chance you won't need to change this value
7: define('DB_CHARSET', 'utf8');
8: define('DB_COLLATE', '');
9:
10: // You can have multiple installations in one database if you give each a unique prefix
11: $table_prefix = 'wp_'; // Only numbers, letters, and underscores please!
12:
13: // Change this to localize WordPress. A corresponding MO file for the
14: // chosen language must be installed to wp-content/languages.
15: // For example, install de.mo to wp-content/languages and set WPLANG to 'de'
16: // to enable German language support.
17: define ('WPLANG', '');
18:
19: /* That's all, stop editing! Happy blogging. */
20:
21: define('ABSPATH', dirname(__FILE__).'/');
22: require_once(ABSPATH.'wp-settings.php');
23: ?>
After setting up a database with the mysql command-line tool, I replaced the DB_NAME, DB_USER, and DB_PASSWORD defaults with the appropriate values, saved it as wp-config.php, and tried to start WordPress. No luck—database connection error. Checked the spelling and tried again—still no luck. Dropped my original database, created a new one, and entered the parameters for that one—still no luck. After a few more rounds, I decided to see if I was in the putative 1% that needed to change line 6. I changed it to
6: define('DB_HOST', '127.0.0.1'); // 99% chance you won't need to change this value
and everything worked fine. I’m still not sure why localhost didn’t work; localhost is set to refer to 127.0.0.1 in my /etc/hosts file. Whatever. Once I got WordPress started, I pushed on.
Importing the old posts
Movable Type has an administration page that lets you export all your blog posts into a simply-formatted text file. WordPress has an administration page for importing posts from a file saved in that format. A match made in heaven—unless your old posts are written in Markdown, which mine are. Here’s what happened.
I figured I had to have the Markdown plugin installed before importing, so I went to Michel Fortin’s site and got both PHP-Markdown-Extra and PHP-SmartyPants. After unzipping the downloaded files, I copied them into the wp-content/plugins directory of my blog and activated them from the WordPress plugins administration page. Then I did the import, which seemed to go quickly and flawlessly; there were no error messages.
When I first looked at the blog, it seemed great. It was styled with the default theme, which I don’t think much of, but I knew I could change that. The important thing was that all the posts were there and their content was intact, and that’s what I thought I had until I looked past the top few posts to an entry that had some programming code. The code was formatted into paragraphs; the line breaks had been lost. (Ironically, the entry with the problem was this one, where I describe how I get nicely-formatted code in my posts.) Further digging showed that all the posts with programming code had the same problem.
Markdown denotes code by indentation; lines that are indented by 4 or more spaces are wrapped in <pre><code> tags. A quick look at the problem entries in WordPress’s editor showed that WordPress had stripped out the leading spaces on all those lines, which is why they were displayed as paragraphs. I posted a plea for help on the Markdown mailing list and was quickly directed (by Sam Angrove) to the culprit in WordPress’s importing script. Line 281 of wp-admin/import/mt.php (in WordPress 2.3.2),
$line = trim($line);
is stripping both the leading and trailing whitespace (including the trailing newline) from each line. Changing that to
$line = rtrim($line, "\n");
fixed the problem. It trims only the trailing newline, which is apparently necessary for the rest of the import logic to work, but leaves the other whitespace intact for Markdown to interpret. Markdown uses leading whitespace for nested lists as well as code, and it uses trailing whitespace for <br> tags.
With the import script changed, I deleted all the posts (using the frightening but useful WordPress Suicide plugin), then re-imported them. Success!
Editing old posts
There’s another gotcha in WordPress for Markdown users. In keeping with this brave new WYSIWYG Web 2.0 world, WordPress’s page for editing posts has, by default, a “visual” text editing interface like a word processor. There’s a tab above the editing field that let’s you toggle between the rich text display and a “code” display, which is meant to allow you to edit the raw HTML of your entry. You would think—or at least, I did think—that using that “code” tab would be the right thing to do for editing in Markdown. But you’d be wrong. Neither the rich text nor the “code” display should be used.
It turns out that when you open a post for editing in WordPress under the default conditions, some of the whitespace gets deleted. This is similar to the importing problem, but has a different solution—one that doesn’t require you to dig into the PHP scripts and make changes. Go to the Users administration page for your blog and click on the Edit action for your user name. When the Edit User page comes up, uncheck the “Use visual editor when writing” checkbox. WordPress will stop stealing your whitespace.
(I didn’t find out about this nasty behavior until the blog was up and running on the new host. And I discovered it not by writing or editing posts—I use TextMate’s Blogging Bundle for that—but by changing the category of several old entries. Even though I made no changes to the content of these posts, the mere act of opening them in the visual editor to change the category caused WordPress to delete some critical whitespace and screw up their formatting. It took quite a while to fix, and I’m still not sure the formatting is back to the way it was.)
Coming up next
I believe my next post in this series will be the last. I’ll describe the templates and CSS that define the blog’s layout.
Update
The new post is here, but covers permalinks.
