For a long time now, I’ve been very frustrated with the blogging platform I’ve used since I started properly blogging here back in 2002. At the time, Movable Type seemed to be the “go to” platform. And it was fine for many years.

I’m in no way a web-developer but a lot of Googling meant that I learnt at least a tiny bit about installing a blog on a server, and the intricacies of MySQL, PHP and so on.

But more recently, Movable Type has been falling by the wayside, and in their latest iteration, they’ve essentially abandoned the private blogger.

Now I know that WordPress isn’t perfect, but there’s a much bigger community developing for it these days than anywhere else. And I certainly didn’t want the simplicity of seemingly popular platforms of today like Tumblr.

So I’ve finally bitten the bullet, and moved this blog over to WordPress.

What follows is probably going to be exceedingly dull to 99% of people who read this blog. So feel free to skip over it. But for the other 1%, or those who encountered similar problems to me, and found this site via Google, there may be the odd helpful hint here.

I was very nervous.

If you look around the web, you’ll find many different guides to making the change. I did a lot of searching before I started, and as I encountered problems along the way. Surely enough people had trodden this route before and published their solutions online?

But they all seemed to have slightly different case usages to my own. Aside from that, many of the techniques and plugins listed are now outdated or have disappeared from sites. More than once I read about an ace plugin that would solve a problem, only to find that it had disappeared, or didn’t work with more recent versions of WordPress.

So I’ll document here what I went through to get WordPress installed and everything moved over.

1. Install WordPress

My Movable Type installation was in www.adambowie/weblog. A simple redirect took people who visited www.adambowie.com to that sub-directory. While I probably could have installed WordPress into that folder, I didn’t. Instead, I installed it to www.adambowie.com. Note the subtle difference!

I actually installed WordPress some time ago, and there are plenty of places online to step you through that process if you run into trouble.

Once installed, I spent a while tinkering with a standard template (Twenty Eleven in my instance) making it similar – but different – to my old blog. That also meant learning about things like Child Templates, and doing a lot of Googling about CSS to discover how to make changes that I wanted.

I also wanted to find some decent methods for commenting, which was always one of the biggest issues I had with Movable Type. In particular, I wanted to include social media commenting, even though I know that quite a lot of people don’t like using it. To be honest, real comments are becoming few and far between with more commentary happening on Twitter or Facebook when I post links to new blogs. In my case, I’ve only switched on Google and Twitter since I don’t really like using Facebook. We’ll see how comment spam goes.

Once I was happy with my new look – and I suspect that it’s a look that will evolve, since it still looks a bit too “WordPress-y” – I moved on to the next stage.

2. Export Movable Type

There’s a pretty decent explanation of the whole migration process on the WordPress Codex, but it didn’t get me the whole way there.

Exporting was perhaps the most painless part of the process. I was coming from Movable Type 5.2.2 and it was just a question of going to Tools > Export Entries. This produces a text file with most of the important stuff from your old blog.

3. Import Into WordPress

Again, a simple stage. Go to Tools > Import and select Movable Type and TypePad. At this point you have to install and activate a WordPress plugin to allow this to happen.

I had just over 3,000 entries with associated comments, and it didn’t take that long to run its course. I only had one user and I had to tie that up with a user in WordPress. Just step through the process as prompted.

The only significant issue I had at this point was that line returns seemed to be broken. In Movable Type I tended to put two line returns between paragraphs and the software seemed to handle that. One way or another, in the export/import process, that broke. And I don’t seem to be the only one who had that problem. I ended up fixing mine by using a bit of CSS that I added to my Child Theme:

br {
display: block;
margin: 10px 0;
content: " ";
}

That seems to be a cross-browser solution with Chome requiring the “content” addition.

It’s a workaround, but leaves me happy with the text layout.

Given that I already had a redirect from www.adambowie.com to www.adambowie.com/weblog it might seem to be just as simple as amending that to point at www.adambowie.com and I’d be done. But that ignores by far the most fiddly part of the process…

4. Redirecting Permalinks

One way or another, I have some decent Google-juice on this site, and there are no doubt all kinds of historic links around the place. So I wanted to ensure that both internal and external links continued to work.

Now there are lots of ways to do this using various techniques. I had some complications in that my old Movable Type structure used a numerical permalink in a single folder, while I wanted WordPress to use a better date/description structure.

So for example my review of the new Google Nexus 7 used to reside at:

www.adambowie.com/weblog/archive/003405.html

Whereas on import into WordPress it could now be found at:

www.adambowie.com/2013/10/short_nexus_7_2

Following the WordPress instructions, and because my old Movable Type blog had padding in the numbers, I ended up creating the following new Index Template within Movable Type:


<?php
require('wp-config.php');
header('Content-type: text/plain');
?>

Redirect Permanent /archives/<$MTEntryID pad="1"$>.html http://www.adambowie.com/archives/<$MTArchiveDate format="%Y/%m/%d"$>/
<?php echo sanitize_title("<$MTEntryTitle$>"); ?>


I must admit that when I did this, I didn’t really understand what I was doing, because my knowledge of PHP is close to zero. Because it was in my old blog’s location, I worried about the “require” code and relative paths. But I should have just followed instructions. WordPress tells you to send the output to a file called redirect.php in the WordPress root directory. So in my instance it meant sending it to ../blog/redirect.php (from /weblog where the Movable Type installation was).

So I created a new “index” by publishing this template.

The bit that wasn’t explicitly explained to this fool was that you then had to run that file in it’s new home. i.e. visit /blog/redirect.php in my browser.

But this did introduce a problem. I got repeated errors because I’d used inverted commas in my blog headings in Movable Type. These had been dutifully output by the Movable Type template, but the surplus inverted commas broke the PHP. So I dutifully edited redirect.php textfile to remove them all. At first it was just searching for ”” but that only found subjects where I’d used inverted commas at the beginning or the end of the subject. Fortunately, the PHP error code gave a line number, and you can track that down in Notepad (which I was using) as long as you turn Word Wrap off. Other text editors are available.

Finally, having done all that, the file ran, although I still got a header error. This may have been down to some kind of surplus white space. But I couldn’t fix that. However I now had the output I needed… sort of.

I copied and pasted the output of my browser into Word, and put some carriage returns back into it using a find/replace with the paragraph character. And I obviously removed the errors at the top.

I had a list of 3,000 or so lines looking a bit like this:

Redirect Permanent /archives/003405.html http://www.adambowie.com/archives/2013/10/01/ short-nexus-7-2013-review

Theoretically, I just needed to paste this into an .htaccess file and I was home and dry. But there are a few things wrong with this code, and I’ll explain them all now, although some took me ages to work them all out.

First of all, I believe that Redirect Permanent is case sensitive, so it should be Redirect permanent although I ended up using Redirect 301.

Secondly, and very specifically to me, it took me ages to spot a random “s” in “archives”. It should have been “archive” in Movable Type and there is no need for “archives” at all in my Movable Type structure!

Thirdly, you’ll notice that there’s a space that’s unnecessary after the date.

Fourthly, the format has too much date info. I only need year and month – not day as well. I don’t blog so much that I need anything beyond a year and month structure. I edited this out by using Excel’s text to columns functionality to get the “day” field into it’s own column which I could remove.

Fifthly, and perhaps most frustratingly, the santize_title PHP command didn’t do what WordPress had done with my blog item titles on import. It used dashes instead of underscores, and on import, WordPress had shortened URLs to the first 15 characters.

I could sort out all those things in Excel with some use of the data functions and so on, alongside CONCATENATE to stitch the bits together. But unfortunately, there were still issues with page names where similar blog entries had meant WordPress had added numbers to keep unique page references.

In the end I used another PHP script I found online to export the true names of each page from WordPress. I named this export_names.php and imported the results into Excel where I tied them up with the Movable Type permalinks.

Here’s the script:

<?php

include "wp-load.php";

$posts = new WP_Query('post_type=any&posts_per_page=-1&post_status=publish');
$posts = $posts->posts;
/*
global $wpdb;
$posts = $wpdb->get_results("
SELECT ID,post_type,post_title
FROM {$wpdb->posts}
WHERE post_status<>'auto-draft' AND post_type NOT IN ('revision','nav_menu_item')
");
*/

header('Content-type:text/plain');
foreach($posts as $post) {
switch ($post->post_type) {
case 'revision':
case 'nav_menu_item':
break;
case 'page':
$permalink = get_page_link($post->ID);
break;
case 'post':
$permalink = get_permalink($post->ID);
break;
case 'attachment':
$permalink = get_attachment_link($post->ID);
break;
default:
$permalink = get_post_permalink($post->ID);
break;
}
echo "\n{$post->post_type}\t{$permalink}\t{$post->post_title}";
}

Finally, I was left with some text that I could place into a file in Notepad and create an .htaccess file that I placed in the root of my blog. Here’s an example line:

Redirect 301 /weblog/archive/003405.html http://www.adambowie.com/2013/10/short_nexus_7_2/

As I understand it, using a 301 redirect tells search engines that the change is permanent, and they’ll update their records to crawl over the new URLs.

Finally, I had to fix my RSS feeds since I suspect, even with the death of Google Reader, feed-readers are the main way that people discover I’ve published new blog entries. That was a straightforward process of adding some extra lines to the .htaccess file redirecting my old XML RSS feeds (RSS 2.0 and Atom in my case) to the relevant WordPress feeds.

Conclusion

Could there still be problems buried in some old entries? Almost certainly. But hopefully most stuff is viewable, and search engines will find their new homes. If something does look badly broken, do let me know!

One final WordPress problem I did have to overcome was with my photos based on html embedded code from Flickr. While the photos displayed fine on large screens, if the display was narrow – e.g. a mobile screen – the Twenty Eleven WordPress theme was resizing the width of the photos accordingly, but leaving the height alone. That made all the photos appear squashed.

The solution is the CSS code from here:

.entry-content img { max-width: 100%; height: auto; }

That fixed it!

I hope some of this helps at least somebody out there.