Recently a client wanted to know if we could have the same blog appear on two different sites with two different domain names. I told her yes, we could. Then I had to go figure out if we actually could.

Yes, kids, your web designer often doesn’t know how to do something until they surf the web and teach themselves how to do it. Self-instruction and a sense of adventure are a big part of this job. The technology field is always changing and there are always new things to be learned. It’s part of the reason this job is fun, because you constantly get to solve new puzzles and do things you didn’t know you could do.

My client was Erin Bried, author of How to Sew a Button: And Other Nifty Things Your Grandmother Knew. That book was so successful that her publisher signed her to write a sister book (er, brother book?) called How to Build a Fire: And Other Handy Things Your Grandfather Knew. Erin already had a blog for the “Button” site, and since both sites have the same how-to theme, she wanted the same blog to appear on both of them.

When I’m trying to learn how to do something new, I start by Googling keywords I think will lead to the answer. This led me to discover three possible ways to solve the problem:

Option #1: Modify the database prefix

This solution required that you install two copies of WordPress on the same host using the same database. (Note: This is not the same as setting up WordPress’s multi-blog option. Instead, these are two independent WordPress installations in separate folders on your web server that are using the same database.) You can install two copies of WordPress in the same database if you specify that they use different table prefixes. By default, all the tables in a WordPress installation start with “wp_” but you can change it to whatever you want in the wp-config.php file.

After you’ve installed both copies of WordPress, you then go into your second installation’s wp-config.php file and rename the table prefix to be that of the first installation. The second WordPress blog will now draw on the data from the first installation, but will remain separate.

This solution seemed way too risky for me to try on Erin’s sites since her first website was live and receiving steady visitors. Messing with the database and the configuration files in this way left a big opportunity for things to go horribly, horribly wrong. I also wasn’t sure if such a modification might screw up any WordPress updates I’d have to install in the future. So, I continued Googling.

Option #2: Crossposting plugin

If you activate the Xpost plugin on your blog, whenever you write a post it will also be posted at another blog that you specify, as long as that blog supports posting via XML-RPC. If someone comments on that post at either site, the comment will be posted on both sites. Having two sets of duplicate data can lead to problems if things get out of synch, but this seemed to be the best solution to the problem that I could find.

I installed the plugin, but because Erin’s sites are both managed within the same WordPress installation using the multiple blog option, the plugin wouldn’t work properly. Thus, I abandoned this approach.

However, as I was Googling for the link to that plugin to include in this post, I found another plugin called Cross Post which claims to work with WordPress MU, though I can’t verify whether it works or not. Regardless, I’m glad I hit a roadblock because it led me to ultimately find a better way to solve the problem.

Option #3: Theme switching

Stumped, I went to the kitchen and made a peanut butter sandwich. By the time I was done chewing, I had thought of another approach to the problem—theme switching. The Theme Switcher plugin allows visitors to use any theme installed on your site by adding the string ?wptheme=ThemeName to the end of the query string. I installed the plugin, visited the original blog with the “Button” theme, added the proper query string to the end of the URL to display the new theme, and voila! The original blog was being displayed with the new theme!

One problem: Now all the pages on the original blog were being displayed with the new theme. Not good. Once you switch the theme, it remains switched until you change it to something else or delete the cookie stored in your browser. I didn’t want visitors of Erin’s “Fire” site to head over to her “Button” site and see the wrong template.

To overcome this issue, I wrote a snippet of code to insert into the header of the new theme that made sure to load the proper theme at the right time:

if (is_page() && ($_SERVER["SERVER_NAME"]=='www.originalThemeSite.com') ) {
	if (! empty($_COOKIE["wptheme" . COOKIEHASH]) && $_COOKIE['wptheme' . COOKIEHASH]!= 'Original theme name') {
		$expire = time() + 30000000;
		setcookie(
			"wptheme" . COOKIEHASH,
			stripslashes('Original theme name'),
			$expire,
			COOKIEPATH
		);
		$redirect = remove_query_arg('wptheme');
		wp_redirect($redirect);
		exit;	
	}
}

This code first checks to see if you’re visiting the original site (not the new one) and if you’re on a page in the site (not a blog archive, search results page, individual entry, etc. which should display the new template). This checks to be sure you’re on a page that should display the original theme, not the new one. If that’s true, it then checks to see if you’ve got a cookie from the Theme Switcher plugin and if that cookie is not set to the original theme. If that’s true, it resets the cookie to the original theme name and reloads the page.

Once those changes were uploaded, the theme switching ran perfectly. To make the link to the blog a bit easier to remember, instead of http://www.domainname.com/blog?wptheme=ThemeName I used the Redirection plugin to send any visitors of http://www.domainname.com/blog to the theme-switched address instead. The same can be achieved by editing the .htaccess file, but I like using the plugin because it allows you to make changes within WordPress without having to FTP.

One other thing to note is that if you have more than two themes installed on your multiple WordPress installation, someone could hypothetically switch the theme of the blog to any of the other themes if they know their names. In that case, it’s good to only install the themes you need, and if you want to be extra safe you can add the code I listed above into the templates of all the themes on your installation.

When I started blogging on my own self-hosted site in 2003, PastaQueen.com, I chose to install the Movable Type blogging software. At the time it was one of the best blogging platforms available, plus it was free. It was also written in Perl, a programming language I was using at my day job at the time. Using Movable Type helped me develop my professional skills as I learned how to install and manage the software.

Now it’s 2010, I no longer program in Perl, and Movable Type is no longer my blogging platform of choice. Over the past several years, WordPress has made great strides to become a free, easy-to-use software package with a lively community of devotees and open source developers–emphasis on easy-to-use. After working with both Movable Type and WordPress, the latter beats the former in all areas. It’s insanely easy to install and update. A developer has probably already written a plug-in for any feature you might desire. And WordPress’s template files are much easier to read and manage than Movable Type’s.

I’ve thought about switching my blog, PastaQueen.com, from Movable Type to WordPress for over a year now, but the thought of transferring over 5 years of archives intimidated me. I was afraid of losing PageRank and search engine links if I failed to redirect my entries properly. However, after a spam attack at the end of 2009, the pain involved in transferring the site seemed worth the pain it would save me via WordPress’s superior spam-filtering abilities.

Here’s a step-by-step guide to the process I went through to transfer over 1000 entries and over 27,000 comments from Movable Type 4.2 to WordPress 2.9 on my blog, PastaQueen.com. Hopefully it will help anyone else out there brave the process of migrating their site from Movable Type to WordPress.

1) Backup everything

First, backup everything. This includes your Movable Type database as well as any images or other media you’ve uploaded to the blog. If something goes wrong during the migration, you’ll be happy you did.

2) Export your entries from Movable Type

Movable Type has a built-in feature to export your blog as a text file. Go to Tools -> Export and click the Export Blog button. At the prompt, save the text file to your hard drive.

3) Import entries to WordPress

I installed WordPress on the same domain as my blog, but in a different folder. Later on, I set up a redirect to point all the old pages to their counterparts on the new page. You can install your new WordPress installation wherever you like, but once you do, go to Tools -> Import and click on Movable Type and TypePad. After you install WordPress, make sure you update it to the latest version.

If you have a small amount of entries, you can use the upload option to import the data. My exported text file was 15.2mb which would have caused the upload to time out. Instead, I used FTP to send the file renamed at mt-export.txt to the /wp-content/ folder as directed.

The importer will then ask you if you want to map a user from Movable Type to an existing WordPress user, or if you want to create new users. After that, WordPress will start importing your comments and entries. In my case, it would time out after the server memory met its maximum limit.

There are two ways to proceed from here. If you have a text editor which handles large files, you can splice the file into smaller pieces that are smaller than your server’s memory limit. However, I was uncertain if I could simply splice the mt-export.txt on any line, since there may or may not be important information above the splice point that I didn’t want to cut out.

It seemed safer for me to just repeat the import process with the same 15.2mb file. Because the importer was smart enough not to import the data it had already imported, it was able to get farther through the process before the memory timed out. I kept repeating this process until everything had been imported. It was time-consuming, but I wasn’t in a time-crunch situation, so I chose caution over speed.

3b) Modify mt.php if your Movable Type entries were set to “Format: convert line breaks”

When I imported my entries, I was puzzled to see that where there were supposed to be two line breaks denoting a new paragraph, there was only one line break. This made my blog messy and hard to read. After some research, I learned this was happening because I had written my Movable Type entries with the Format drop-down set to “Convert link breaks.” When the entries were imported, WordPress did not translate this formatting correctly.

Luckily, there is an easy fix that I found on the site On a Lark. Open up wp-admin/import/mt.php and replace this line:

// Processing multi-line field, check context.

if( !empty($line) )
$line .= “\n”;

with this:

// Processing multi-line field, check context.

if( !empty($line) )
$line .= “\n\n”;

After I changed the importer, I deleted my WordPress installation and reinstalled it since this was faster than deleting all the poorly formatted entries and comments. I then uploaded the modified mt.php and imported my entries with the correct formatting.

4) Use Movable Type Blog Import Utilities to import tags

The WordPress importer script has one major flaw: it doesn’t import your tags. Tags are an important part of my site structure and I didn’t want to retag all my entries. Instead, I used the Movable Type Blog Import Utilities written by Simone Carletti to bring them over.

I downloaded the mt-utils.php file and uploaded it to the wp-admin/import/ folder. Now when I went to the Tools -> Import page I was presented with another option:

I clicked through to get to the tag importer, which required me to create a new template in my old Movable Type installation that would generate a text file I would use to import my tags. I did so, saved the text file and uploaded it according the tag importer’s instructions. Then I was greatly befuddled when it didn’t work.

Then I realized that my previous editing of the mt.php script had caused the tag importer not to work because it was trying to match the body text of the Movable Type entry with the body text of the WordPress entries. My WordPress entries had an extra line break inserted into them, causing a mismatch. To make the mt.php script work I found this line:

foreach($posts as $post) {
if ($postId = post_exists($post->title, $post->content, ”)) {

and replaced it with this:

foreach($posts as $post) {
if ($postId = post_exists($post->title, ”, ”)) {

Then I found this line:

} else if ($postId = post_exists($post->title, $post->content, ”)) {

and replaced it with this:

} else if ($postId = post_exists($post->title, ”, ”)) {

I tried importing my tags again and this time it worked.

5) Translating my Movable Type templates to a WordPress theme

Next, I had to go line by line through my Movable Type templates and translate them to a corresponding WordPress theme. I had to pay particular attention to what URL each link and image was pointing to and update it to the new folder on my site where WordPress lived. I also had to install some WordPress plug-ins to make some items in my sidebar functional, such as my Recent Posts widget.

This was the most time-consuming part of the process. I chose to do it after I’d imported all my entries so I could make sure everything would display properly with the actual content in it. I chose to leave any images I’d uploaded for posts in my old directory structure since I didn’t want to update every post to point the images to my new WordPress folder.

After the theme was complete, I double-checked all the pages from the archives, search pages, tag archives, and home page, etc. Now we were ready to launch!

6) Setting up redirects and launching!

Because my WordPress entries were in a different folder than my Movable Type entries, I needed to redirect the old posts to the new posts. I wanted to do this without breaking any links, especially any links from search engines. The best way for me to do this was to use the htaccess tool in the Movable Type Blog Import Utilities.

Again, I went to Tools -> Import and clicked on the MT Blog Import Utilities, this time going to the htaccess tool. Again, I had to add a new template on my old Movable Type installation to create a text file I uploaded to the utility. Once I did this, the utility generated code that I pasted in the .htaccess file that lives in the root directory of my old blog. This file can be used to tell search engines and browsers that a page has moved. I had to do some slight tweaking to the Movable Type template to get my URLs correct, but once I did, I was extremely happy with the results! I updated my htaccess file with the results and voila, the new site was launched! I double-checked the htaccess file by trying to access some of my old Movable Type generated files, and each time I was redirected to the WordPress version immediately.

7) Other items to consider

Each blog installation is unique, but another thing you might need to redirect are your site feeds. I added lines to my htaccess file that redirected my Movable Type feeds to the new WordPress feeds. Both Google Reader and Bloglines adjusted to the change seamlessly.

For now, I still have my Movable Type installation on my server, just in case I realize I need to move something over that I’ve forgotten. After a few more weeks I’ll probably back it up and then take it down.

Conclusion

Moving my Movable Type blog to WordPress took the better part of a weekend. I’m very glad I made the change though. Overall, it was slightly less painful than I imagined it would be, but I imagined it would be like chewing on a porcupine. The Movable Type Blog Import Utilities saved me a lot of time since the redirects were the part of the process I dreaded most. Thank you to Simone Carletti for writing those and making them publicly available.

If you too make the move from Movable Type to WordPress, your unique blog installation might run into issues that I didn’t have here. Hopefully the vast resources on the Internet will be able to help you through any situation. Good luck!