For a long time now, I\u2019ve been very frustrated with the blogging platform I\u2019ve used since I started properly blogging here back in 2002. At the time, Movable Type seemed to be the \u201cgo to\u201d platform. And it was fine for many years. <\/p>\n
I\u2019m 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.<\/p>\n
But more recently, Movable Type has been falling by the wayside, and in their latest iteration, they\u2019ve essentially abandoned the private blogger. <\/p>\n
Now I know that WordPress isn\u2019t perfect, but there\u2019s a much bigger community developing for it these days than anywhere else. And I certainly didn\u2019t want the simplicity of seemingly popular platforms of today like Tumblr.<\/p>\n
So I\u2019ve finally bitten the bullet, and moved this blog over to WordPress.<\/p>\n
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.<\/p>\n
I was very nervous. <\/p>\n
If you look around the web, you\u2019ll 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?<\/p>\n
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. <\/p>\n
So I\u2019ll document here what I went through to get WordPress installed and everything moved over.<\/p>\n
1. Install WordPress<\/B><\/p>\n
My Movable Type installation was in 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.<\/p>\n 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.<\/p>\n 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\u2019t 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\u2019ve only switched on Google and Twitter since I don\u2019t really like using Facebook. We\u2019ll see how comment spam goes.<\/p>\n Once I was happy with my new look – and I suspect that it\u2019s a look that will evolve, since it still looks a bit too “WordPress-y” – I moved on to the next stage.<\/p>\n 2. Export Movable Type<\/B><\/p>\n There’s a pretty decent explanation of the whole migration process on the WordPress Codex<\/a>, but it didn’t get me the whole way there.<\/p>\n 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<\/strong>. This produces a text file with most of the important stuff from your old blog.<\/p>\n 3. Import Into WordPress<\/B><\/p>\n Again, a simple stage. Go to Tools > Import<\/strong> and select Movable Type and TypePad<\/strong>. At this point you have to install and activate a WordPress plugin to allow this to happen.<\/p>\n I had just over 3,000 entries with associated comments, and it didn\u2019t 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.<\/p>\n 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\u2019t 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:<\/p>\n That seems to be a cross-browser solution with Chome requiring the \u201ccontent\u201d addition.<\/p>\n It\u2019s a workaround, but leaves me happy with the text layout.<\/p>\n Given that I already had a redirect from 4. Redirecting Permalinks<\/B><\/p>\n 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.<\/p>\n 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<\/I> structure.<\/p>\n So for example my review of the new Google Nexus 7 used to reside at:<\/p>\n Whereas on import into WordPress it could now be found at:<\/p>\n Following the WordPress instructions<\/A>, and because my old Movable Type blog had padding in the numbers, I ended up creating the following new Index Template within Movable Type:<\/p>\n I must admit that when I did this, I didn\u2019t really understand what I was doing, because my knowledge of PHP is close to zero. Because it was in my old blog\u2019s location, I worried about the \u201crequire\u201d code and relative paths. But I should have just followed instructions. WordPress tells you to send the output to a file called So I created a new “index” by publishing this template.<\/p>\n The bit that wasn\u2019t<\/I> explicitly explained to this fool was that you then had to run<\/I> that file in it\u2019s new home. i.e. visit But this did introduce a problem. I got repeated errors because I\u2019d 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 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\u2019t fix that. However I now had the output I needed\u2026 sort of.<\/p>\n 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.<\/p>\n I had a list of 3,000 or so lines looking a bit like this:<\/p>\n Theoretically, I just needed to paste this into an First of all, I believe that Secondly, and very specifically to me, it took me ages to spot a random \u201cs\u201d in \u201carchives\u201d. It should have been “archive” in Movable Type and there is no need for “archives” at all in my Movable Type structure!<\/p>\n Thirdly, you\u2019ll notice that there\u2019s a space that\u2019s unnecessary after the date. <\/p>\n 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.<\/p>\n Fifthly, and perhaps most frustratingly, the 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. <\/p>\n In the end I used another PHP script I found online<\/a> to export the true names of each page from WordPress. I named this Here\u2019s the script:<\/p>\n include \"wp-load.php\";<\/p>\n $posts = new WP_Query('post_type=any&posts_per_page=-1&post_status=publish'); header('Content-type:text\/plain'); Finally, I was left with some text that I could place into a file in Notepad and create an As I understand it, using a 301 redirect tells search engines that the change is permanent, and they\u2019ll update their records to crawl over the new URLs.<\/p>\n 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\u2019ve published new blog entries. That was a straightforward process of adding some extra lines to the Conclusion<\/strong><\/p>\n 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!<\/p>\n 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.<\/p>\nwww.adambowie\/weblog<\/code>. A simple redirect took people who visited www.adambowie.com<\/code> to that sub-directory. While I probably could have installed WordPress into that folder, I didn\u2019t. Instead, I installed it to www.adambowie.com<\/code>. Note the subtle difference!<\/p>\nbr {
\n display: block;
\n margin: 10px 0;
\n content: \" \";
\n}<\/code><\/p><\/blockquote>\nwww.adambowie.com<\/code> to www.adambowie.com\/weblog<\/code> it might seem to be just as simple as amending that to point at www.adambowie.com<\/code> and I\u2019d be done. But that ignores by far the most fiddly part of the process…<\/p>\nwww.adambowie.com\/weblog\/archive\/003405.html<\/code><\/p>\nwww.adambowie.com\/2013\/10\/short_nexus_7_2<\/code><\/p>\n
\n<?php
\nrequire('wp-config.php');
\nheader('Content-type: text\/plain');
\n?>
\n
\nRedirect Permanent \/archives\/<$MTEntryID pad=\"1\"$>.html http:\/\/dev.adambowie.com\/archives\/<$MTArchiveDate format=\"%Y\/%m\/%d\"$>\/
\n <?php echo sanitize_title(\"<$MTEntryTitle$>\"); ?>
\n<\/MTEntries><\/code><\/p><\/blockquote>\nredirect.php<\/code> in the WordPress root directory. So in my instance it meant sending it to ..\/blog\/redirect.php<\/code> (from \/weblog<\/code> where the Movable Type installation was).<\/p>\n\/blog\/redirect.php<\/code> in my browser.<\/p>\nredirect.php<\/code> textfile to remove them all. At first it was just searching for \u201d\u201d<\/code> but that only found subjects where I\u2019d 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.<\/p>\nRedirect Permanent \/archives\/003405.html http:\/\/dev.adambowie.com\/archives\/2013\/10\/01\/ short-nexus-7-2013-review<\/code><\/p>\n.htaccess<\/code> file and I was home and dry. But there are a few things wrong with this code, and I\u2019ll explain them all now, although some took me ages to work them all out. <\/p>\nRedirect Permanent<\/code> is case sensitive, so it should be Redirect permanent<\/code> although I ended up using Redirect 301<\/code>. <\/p>\nsantize_title<\/code> PHP command didn\u2019t 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. <\/p>\nexport_names.php<\/code> and imported the results into Excel where I tied them up with the Movable Type permalinks. <\/p>\n<?php<\/p>\n
\n$posts = $posts->posts;
\n\/*
\nglobal $wpdb;
\n$posts = $wpdb->get_results(\"
\n SELECT ID,post_type,post_title
\n FROM {$wpdb->posts}
\n WHERE post_status<>'auto-draft' AND post_type NOT IN ('revision','nav_menu_item')
\n\");
\n*\/<\/p>\n
\nforeach($posts as $post) {
\n switch ($post->post_type) {
\n case 'revision':
\n case 'nav_menu_item':
\n break;
\n case 'page':
\n $permalink = get_page_link($post->ID);
\n break;
\n case 'post':
\n $permalink = get_permalink($post->ID);
\n break;
\n case 'attachment':
\n $permalink = get_attachment_link($post->ID);
\n break;
\n default:
\n $permalink = get_post_permalink($post->ID);
\n break;
\n }
\n echo \"\\n{$post->post_type}\\t{$permalink}\\t{$post->post_title}\";
\n}<\/code><\/p><\/blockquote>\n.htaccess<\/code> file that I placed in the root of my blog. Here\u2019s an example line:<\/p>\nRedirect 301 \/weblog\/archive\/003405.html http:\/\/dev.adambowie.com\/2013\/10\/short_nexus_7_2\/<\/code><\/p>\n.htaccess<\/code> file redirecting my old XML RSS feeds (RSS 2.0 and Atom in my case) to the relevant WordPress feeds<\/a>.<\/p>\n