Movable Type to WordPress

Over at my brother Stefan’s blog, he’s been running Movable Type for years. It bugged be because his server was slow, the theme was dated, it lacked a good archive page, etc.

Mostly I did not like the look or the speed. Stefan takes really good pictures and I thought he should have a web site that can show off some of his work. What I ended up showing him was good enough that he told me to go ahead and do it.

Read on for what I had to do to make it all work.

Performance

The old Movable Type blog pinned his server’s CPU all the time. When you ran “uptime” you got numbers >20. His is a single CPU system; a 1 means the CPU is used 100% and processing jobs as soon as it can. A uptime number greater that the number of CPUs you have indicates that jobs are queuing up. A number less than the 1.0 means that the CPU is idling some of the time.

When I first installed WordPress on his server, PHP was not killing his server but was not as responsive as I’d hoped. I installed eAccelerator as a PHP module and cache the PHP scripts to disk. That did the trick nicely and his system is very responsive and almost never breaks a sweat.

I also added WP Super Cache and setup Mysql to use a query cache. WP Super Cache dynamically creates static web pages out of the WordPress generated pages. If you change anything (like adding a comment) the old page gets removed from the cache and replaced with a new one. The saved pages in the cache do not use PHP or make mysql queries since the file is just HTML. It gives the server a break while letting users get the content faster.

The theme

I wanted to pick out a 3 column theme that was not too decorated and little plain. The reason for this is that I wanted people to focus on Stefan’s header and any images he posts.

I chose the three column Cutline theme for the website. It’s a clean theme and lets you concentrate on the content. Also I figured that the rotating image would show off some of his pictures.

There was hardly anything I had to do to the theme. The r_sidebar.php file was referencing id=”sidebar” so XHTML validation was off. ID is a unique identifier and can only be used once in a web page, class can be used over and over again.

That was a simple matter of duplicating the few sidebar elements in the CSS style sheet. I made it r_sidebar for the right most column. That permits it to validate. Duplicating the classes was not necessary but if I want to style the right sidebar differently from the first then it will be easy to do so.

Stefan likes to use the calendar widget so I added this to the style sheet:

#calendar_wrap #wp-calendar { width:205px; text-align:center; border-collapse: collapse; }

This sized the calendar nicely in the column. I wanted to use the search widget but could not work out how to style it. Not really a problem because all I had to do was copy the text from searchform.php into the text widget.

I put the widget title as “Search it!” and replaced <?php bloginfo(‘home’); ?> with the blog home http://www.epyon-1.com/blog/ and poof the search form was styled correctly. I could have used Otto’s execphp widget but this was easier.

The theme without any content or bells and whistles validates as XHTML Transitional. Stefan’s imported posts do not validate and once I added some more widgets, validation went out the window. Oh well, I tried. I’m a fan of that standard and except for one post my blog validates as XHTML 1.0 Strict.

I ended up using an Ajax Google plugin for the search; it’s cooler looking. Doncha’s Flickr RSS widget was added as well as Amazon Smartlinks.

Permalinks

Exporting the old MT posts into WordPress went without a hitch. The permalinks, oh yeah right. I wanted to switch the blog to a typical WordPress format of %year%/%monthnum%/%day%/%postname%.

The old format was %year%/%monthnum%/%postname%.php, with under score characters between the postname words.

The underscore was manageable and I could have scripted that.

At some point Stefan’s post format was limited to 15 characters which he changed to 256 characters. That meant some posts were

/blog/archives/2007/10/long_title_here.php

and others where

/blog/archives/2007/10/long_title_here_that_keeps_going.php

Gah, if it was consistent for all the posts then I would have sent everything to a redirect.php script and worked it out.

I installed the Google XML Sitemaps plugin and I ended up creating a text file from the sitemap.xml file. This let me get all the new URLs and I began massaging the .htaccess file by hand.

Here is a sample:

RewriteRule .*archives/2008/01/it_has_got_to_be_illegal.php.* http://www.epyon-1.com/blog/2008/01/21/it-has-got-to-be-illegal/ [R=301,L]

I used the .* before and after because the file path actually exists and the wild cards ensure that the redirection gets hit.

The rewrite rules are 316 lines long but using a complex tool *cough* Excel with the two columns next to each other *cough* I was able to match up the old with the new in less than 30 minutes. Google has already updated most of their links with the new format, and if you do hit the old URL it redirects correctly to the new URL.

I’d have preferred a PHP script to handle the redirect and wrote a small one for the index.php files.

For archives such as/blog/archives/2006/10/ MT had placed a index.php with the archive for that month. I replaced the generated index.php with one that had this in it:

<?php
$url=’http://www.epyon-1.com/blog’;
$whereami=getcwd();
$path_to_cut=’/\/var\/www\/html\/blog\/archives/’;

$new_path=preg_replace($path_to_cut,”,$whereami);
$location=”Location: “.$url.$new_path.”/”;

Header(“HTTP/1.1 301 Moved Permanently”);
Header($location);?>

That way when someone managed to hit an old archive page it redirected the user to the new page. I could have used more .htaccess rewrite rules (and may yet) but this was pretty expedient.

At some point I’ll clean up the file system but some of Stefan’s posts reference image files in those directories. There is no reason for keeping the old file structure and once the old URLs get out of Google I’ll clean up the .htaccess file as well.

Adding Asides

I turned Stefan onto asides. Adding that to Cutline was also pretty simple. In the index.php file I inserted

<?php //substitute your asides category number here ?>
<?php if ( !in_category(76) && !is_single() ) { ?>

right after the line that has

<?php while (have_posts()) : the_post(); ?>

and right before the line that reads

<?php endwhile; ?>

I put in these lines

<?php } else { ?>

<ul class=”asides_entry”>
<li>
<?php echo wptexturize($post->post_content); ?>
<?php comments_popup_link(‘(0)’, ‘(1)’,'(%)’)?> <?php edit_post_link(‘(edit this)’); ?>
</li>
</ul>
<br />

<?php } ?>

In the style.css I inserted right above the .entry line

.asides_entry { font-size: 1.4em; line-height: 1.65em; border-left: 3px solid red; }

.asides_entry li {padding: 0 25px; list-style:none; }

The aside was copied and modified from the existing .entry styling. The asides are now formatted the way Stefan likes.

Firefox and rotating images

If you use a rotating.php script to output a random image and you use Firefox, then you’ll notice that the image does not often change unless you CTRL-F5 the page. Firefox does not reload the image based on a redirection because the result is already cached. This is a Firefox issue/feature; on Internet Explorer the image gets refreshed frequently.

On my blog I use Matt’s rotate.php script in my style.css file. Cutline displays the header image as a simple <img src=”URL”>. If you use the redirection method then you get the same results meaning the image will not randomly redirect.

The conditional header code will switch when you go from the front page to the archives, but I wanted to have a random header each time the page is loaded.

Using Javascript is the answer and inserting code like this into the header.php does the trick:

<div id=“header_img”>

<script type=“text/javascript”>
<!–
/*
Random Image Link Script
By Website Abstraction (http://www.wsabstract.com)
and Java-scripts.net (http://www.java-scripts.net)
*/

function random_imglink(){
var myimages=new Array()
//specify random images below. You can have as many as you wish
myimages[1]=”http://www.epyon-1.com/images/Cable-01.jpg”
myimages[2]=”http://www.epyon-1.com/images/waiting.jpg”
myimages[3]=”http://www.epyon-1.com/mages/taxi-bike.jpg”

var ry=Math.floor(Math.random()*myimages.length)

if (ry==0) {
ry=1
}
document.write(‘<img src=”‘+myimages[ry]+’”>’)
}

random_imglink()
//–>
</script>

</div>

That’s a simple piece of JavaScript but I wanted it to be dynamic, meaning you just put files into the images directory and the JavaScript adjusts.

I modified Matt’s rotate.php script so that instead of generating 301 Redirects, it generates the JavaScript. It works well and the images get changed with every visit to any part of the blog. You can get a copy of the file from this link.

Conclusion

That’s pretty much it. The blog now is more updated and the responsiveness is very good. Stefan finds it easier to manage and is blogging more.

The performance increase switching to WordPress and doing some tweaks was dramatic. I’m sure that the old Movable Type software could have been made to perform better but I don’t use it and the migration really was quick and simple.