arrow-left arrow-right brightness-2 chevron-left chevron-right facebook-box facebook loader magnify menu-down rss-box star twitter-box twitter white-balance-sunny window-close
Dust in the wind
4 min read

Dust in the wind

I’m always telling myself to stop writing about the minor behind-the-scenes goings-on here, but of course I never do. I guess I’m OK with only a couple of people finding it interesting as I like this sort of thing when others do it.

So, without further ado, I present to you more banal and trivial nonsense.

After a week with the ‘new’ layout, I decided I needed the menu back at the top. Not only was I finding myself kind of annoyed by its new location in the side menu, but I also felt there was no real navigational anchor (even though the links were in essentially the same location on every page).

I spent a good part of the day trying to make IE 6 play nice (yeah, the story of every web developer’s life, ridiculous) with a dynamic rollover thingy I whipped up in JavaScript,¹ that produced a menu when you hovered over a + symbol in the top right corner of the site (have I mentioned I’m a minimalist?). After getting everything working on every major browser, I decided to scrap it. Surprise.

Long story short (oh trust me, I could write a lot more on this), the old menu is back at the top, though now, for the first time in this site’s history, it’s a client-side image map instead of plain text (I just can’t get enough of DIN Schrift MittelSchrift).

Speaking of wasting unbelievable amounts of time, I spent nearly 10 hours this weekend migrating the entire site from WordPress to Movable Type (for no overriding reason). However, and probably not surprisingly, all the work was for naught — I’m still using WP.

About a year ago, I wrote a three-part (one, two, three), 3,400-word piece regarding a possible move back to Movable Type. A lot has changed since then — Movable type just released version four and now both systems support a common import/export format.

Though I ultimately decided to stick with WordPress, I thought I’d discuss some of the issues I encountered during the migration.


Movable Type now supports the importation of WordPress eXtended RSS (WXR) files, the format through which WP exports. Importing was far easier this time than last, but it wasn’t perfect. The biggest problem I had was HTML entities in some of my post titles; they completely broke the import script. Luckily, not too many of my titles had entities, so it wasn’t that difficult to manually swap them out for their character equivalents.

The bigger problem was that each time I tried to import the file, it would import every post until it choked on a post it couldn’t read, which meant that I had to delete all the imported posts multiple times before finally getting a clean import (after removing all the entities from the titles). It would have been nice if the import script validated the file before it actually attempted to import entries.

Another problem with the import was that it seemed to ignore my plea that it not format the posts’ text (there’s a text formatting drop-down, and one of the options is none), and instead chose to convert line breaks. The problem is that I don’t currently wrap the bits in paragraph tags until they are displayed, which means they were getting nested paragraph tags at the output, and there was no way for me to batch-change the format option on every bit to none. Yes, I could have removed the double paragraph tags at the output, but that would have required me to change the way the bits are saved, something I didn’t want to do.

The import also broke all of my post slugs. By default, Movable Type limits slugs (which it calls basenames) to 30 characters; if your slugs are longer than this, they get truncated. Sure, this is easily remedied by deleting the weblog, creating it again, setting the basename value to some larger number, and then re-importing, but it would be easier (and logical) for the importer to ignore the defined basename length so as to not break URIs between systems.

After getting everything imported, I decided to divide the posts into two separate weblogs — one for regular posts and one for bits. To do this, I had to delete all bits from the weblog (100 at a time — the max allowed), export the remainder, delete the weblog entirely, import everything again, delete all regular posts from the weblog, export the remainder again, delete the weblog entirely again, create two new weblogs, and import into each. I realize this is probably a niche need, but it would have been nice if I could have simply selected a category (or tag, or whatever) and created a new weblog with only those posts. I guess I could have cloned the weblog and then deleted from each those posts that no longer ‘belonged,’ but then my post IDs would have been all over the place.


Once everything was imported correctly into the two weblogs, I set out to use the now baked-in multi-blog feature to enable the weaving of bits and regular posts on the main page. Without too much fuss, and with Google’s help, I was able to get interleaved posts working on the index page fairly quickly.

After most of the major issues had been worked out, it was time to decide how I was going to serve the pages. If [processing] time weren’t an issue, I’d prefer the pages be built statically, but that no longer makes real-world sense given the current number of posts here. No, I don’t have comments to deal with, but full rebuilds would still take more time than I could probably stand. In light of this, I decided to try out the dynamic options.

I was quite surprised that once I turned on dynamic publishing (for everything), it just worked. Well, sorta. It worked on all archive files (including individual entry archives), but threw a 404 on the main index page. I could not resolve this to save my life, but to be fair, it could have had something to do with my 775-line htaccess file (which is part of the reason I was so surprised it worked at all). Regardless, I gave up on trying to find a solution and instead chose to publish only archive templates dynamically, which seemed to fix the issue.

After jumping through all these hoops (and many more), I completely scrapped the installation, but I guess I now know it’s still a viable option should I want/need to ditch WordPress at some point.

  1. I wanted a pure CSS solution, but IE 6 (of course!) doesn’t support the :hover pseudo class on anything but anchors.
You've successfully subscribed to Justin Blanton.
Success! Your account is fully activated, you now have access to all content.