After using it a bit further, it looks like WordPress will work out well. In particular I like:

1) Changes are reflected immediately. With MT I had to load the admin URL, select the template section, select the Main Index template, edit in the change, save it, hit the Rebuild button, and wait a while, just to update the numbers on the front page. With WordPress I can just edit the main index file in a plain old text editor.

2) Experimental changes are easier to do. Modifying the style sheet or templates in MT often caused temporary disruptions while I worked out problems, and required a lot of rebuilding. Now I just make a copy of the main index page or style sheet, (e.g., ‘index-test.php’), experiment with changes on it, and then copy it over the regular page when it’s complete, with no disruptions.

3) Posts can be given times and dates in the future, and will remain hidden until that time arrives and then automatically become visible. Writing posts a couple days in advance like this lets me sit on them a while and think of better ways to word things, more points to add, etc., without having to remember to go back and ‘activate’ them later on like a regular draft post.

It also lets posts be released on a more regular schedule, without me having to write them on that same schedule. If I’m feeling productive some night I could write out a half-dozen posts, and then automatically release one per day over the next week instead of overwhelming the site all at once, or trying to remember day-by-day what I was going to write about.

4) The handling of multiple and subdivided categories in WordPress is much better. Subcategories appear as expected in the category lists, and when multiple categories are specified they’re treated equally instead of being separated into ‘primary’ and tacked-on ‘secondary’ categories. (Though for some reason selecting a subcategory does not automatically select its parent category.)

5) Being PHP-based should allow for more flexibility. MT limited you to what you could do through their specific substitution tags, but if I wanted to I could use PHP and MySQL functions to extract whatever raw data I want from the WordPress database.

6) Posts can be split into multiple pages if they’re *really* long.

7) There’s a link management system built-in (i.e., the links in the upper-right corner). It’s not really necessary since you can always add links to the template yourself, but it works reasonably well enough.

There are a few downsides too though:

1) Since everything is dynamically generated, it doesn’t get cached. Just browsing around the site generates a lot more page hits than you’d normally expect, and frequent hits from spiders and aggregators keep getting full sets of new data instead of the ‘304 you’ve-already-got-that’ response. At least it’s all text.

2) The post preview is on the same page as the edit boxes for the post itself. This is kind of a mixed blessing as it doesn’t require you to go to a separate page just to preview, but it can also have unexpected side effects. I have one draft post that I can’t edit anymore because I accidentally put an HTML refresh directive in it and as soon as I go to edit the post it redirects to the new page.

3) The user registration system isn’t quite as complete as I’d have liked. Ideally registered users should be able to be marked for automatic access to protected posts, automatic clearance on comments while holding unregistered ones for approval, and such, but right now it doesn’t seem to do much besides let those users write their own posts. The groundwork is there though, so maybe in a future version…

4) Comments and trackbacks are mixed together, though they serve different purposes. There is a hack out there to fix that and put them in their own separate sections on the page though, and it’s not like I get a lot of trackbacks. :-)

Though I’ve converted the site over to WordPress, the old Movable Type archives are still there and accessible. This presents a bit of a problem, because how do I get rid of them? Search engines are going to continue referring to them for a while, so it would make sense to leave them in place so the searcher doesn’t get a 404, but leaving them there will just keep them in the search engines even longer. Redirecting all requests that point at the old archives to the new main page would be unfriendly, since it wouldn’t be what they were looking for.

What would be preferable is to have requests to the old pages automatically redirect to the same article under the new site. The major problem there though, is that the article numbers under the two systems are not the same; what was article #77 under MT is now #74 under WordPress, for example. It’s not a simple single offset for all the articles either, since MT exported them in the order they were posted, not by numerical order.

So, clearly what’s needed is some kind of script that will map the old numbers to the new numbers. Figuring that PHP might be worth a look, since WordPress itself is implemented in it, I brought up the PHP Manual, opened some of the WordPress code in an editor as a sample, and hacked out the following: redirect-mt.php

Instead of mapping each and every article number, it takes advantage of the fact that large ranges of numbers have the same offsets, so all it has to keep track of is the boundaries of those ranges. It took longer than I thought it would to extract those ranges from the MT articles, but the generation of that list could be automated, too. I was just lazy.

This script will remap the article numbers, but I still have to capture the requests and feed them to this script. Fortunately that’s a fairly simple addition to the .htaccess:

# Redirect Movable Type archive requests to the WordPress articles,
# through a remapper script
RewriteRule ^archives/([0-9]{6}).html$ /heide/redirect-mt.php?index=$1 [QSA]

It seems to work well enough, though I’m sure there’s probably some better way. I don’t think I’ll put PHP down on the resume quite yet… :-)

Yes, the paint is new, but the place is still the same. I spent a chunk of the afternoon converting the site over from MovableType to WordPress and things *seem* to work, though I’m sure there are a few broken links here and there.

Why switch? JUST ‘CAUSE.

Oh okay, there are a couple reasons. MT used statically generated pages, which are nice for keeping the server load low but not so nice for incorporating dynamic data. WordPress has a few additional nifty features like password-protected entries and comment moderation. MT does have some similar features on the way, but the new version is also in a bit of a licensing kerfuffle. And finally, I just like tinkering with things.