Sep 9, 2006 8 min read

Pondering a move back to Movable Type (3)

Please read part one and part two before reading the rest of this post.

Let me first point out that a lot of people have written to me about the two previous posts in this ‘series’ and it seems many of them are in the same boat as me and are thinking about maybe coming back to MT. While the reasons for wanting to switch again vary wildly, I’m definitely not alone.

At the tail end of the previous post I said the following:

Basically, I just don’t think that DreamHost, my current webhost, will give me the CPU time I need to rebuild the entire site (at least not without using MT’s dynamic PHP publishing system on my archives, which goes against the idea of keeping everything static, something I may or may not want to do again), and this could be a very big problem should I ultimately decide to move back to MT.

I’ve yet to bring it up publicly, but this little series of posts has kind of put my back up against a wall and instead of explaining in-depth the issues I’ve had with DreamHost as of late, I encourage you to check out Mike Davidson’s post on the matter (aptly titled Thoughts on the DreamHost meltdown). As he points out, he makes around $30,000(!) a year in referrer fees from DreamHost, and while I don’t make nearly that much, I have pulled in a pretty respectable amount from them and so it is with much hesitation that I dare say anything less than flattering about their service.

I agree with just about everything Mike says, including the update on the DH situation, where he remarks, After an unusual and unfortunate two-month span of questionable performance, Dreamhost appears to be back to its previous levels of reliability for me. That said, the fact that the default, static version of MT is essentially unusable on their machines doesn’t sit too well with me. I understand that MT can be a resource hog when doing a full rebuild of a large website, but this is something that must be done from time to time and so the server should allow it unless your aggregate CPU time for the day starts to inch over the threshold set for your particular account.¹

I’ve a hunch DH is monitoring any process that uses the mt.cgi file (MT’s engine) and is killing it after a certain amount of CPU time, a certain small amount, is spent on it. I say this because almost every time I try to rebuild, no matter the number of entries, it gives me generic internal server errors.

For those unfamiliar with how MT works, the long and short of it is that it uses templates (individual archives, indexes, etc.) to create static (X)HTML pages that are saved as such on the server. While MT now gives you the option of building pages dynamically (a combination of this and static files will probably be what I ultimately use if I end up switching back to MT), this doesn’t really concern me at this juncture. I’m interested in the fact that I can’t rebuild my website. I mentioned in the previous post that importing all of my entries at once (nearly 1000 of them) was a no go as MT told me the file was too large. To get around that I broke the file up into smaller pieces. I tried to do the same with the rebuild. I selected 125 posts. It broke. I selected 75 posts. It broke. 50. It broke. 25. It worked about every third time. Sometimes just rebuilding a single template or post would cause the server to return a 404 error (not found) on the mt.cgi file. Huh?

Obviously, then, there is just no way to run MT on DH without the dynamic publishing turned on (at least for the archives). If you’re using MT to run a 1000+ post weblog on DH and are not using dynamic publishing, I’d love to hear from you; I’ve many questions to ask. I’d also like to hear from you if you’ve got a hosting recommendation. I realize nothing out there is going to compete with DH on disk space and bandwidth, and it will be hard to give up the nightly syncing of all my photos (discussed in the last section of this post), not to mention the referrer money mentioned above, but I would like to at least have a solid backup plan should I eventually decide to leave DH (it’s unlikely, but…).

Should I really attempt the move?

Probably not. Will I? Yah, probably. I’m in too deep now to stop myself. Like I said before, I’m just kind of bored and want to peek under the hood of MT to see what’s changed since I left. I can’t help it.

What’s left to do?

Hrm. Where to begin? As I said in the initial post:

I think part of me just wants to see if this can be done [relatively quickly]. My WP setup is a very customized one, far removed from the theme system most people use and rife with hacks, workarounds, and one-off plugins (most of which I’ve never released). It will be interesting to see if I can achieve the same with MT.

The following is what’s currently floating around in my head regarding things that need to be done.

Clean up all of the HTML entity stuff that got a little mangled from the initial export/import and then install SmartyPants (though it would seem a bit superfluous given that I run SmaryPants + Markdown locally through TextMate as I type up my posts).
Fix my categories (see next section).
Create a completely separate weblog for the linked-list posts.
Come up with a way to interlace the index page with both regular posts and linked-list posts (the same as I currently do now with WP). It seems to me that the MultiBlog plugin is exactly what I need; the documentation is a bit wanting, but I’m sure I can figure it out by looking at the code.
Get all of my crazy .htaccess rules to play nice with the rules required by MT for its dynamic publishing (if I ultimately go that route, and I may be forced to).
Get all of my templates how I want them. This is going to take a while and will involve creating a ton of MT modules that will probably be structured very similarly to the PHP modules I currently use in my WP templates.
Come up with an archives system similar to that produced by my Smart Archives plugin for WP. Ironically, this plugin was actually modeled after something I initially did for Movable Type, though the MT thing was much simpler.
Implement some code I wrote for MT way back when to do relative dates (I also wrote a WP plugin to accomplish the same). I’ve noticed that MT now has relative dates built into the system, but it looks like they only go back a week. I’ll have to change that.
I haven’t looked into MT’s public search routine at all, but I might have to change some things regarding that as well, especially if it’s as limited as WP’s, but I highly doubt that.
[Hopefully] find a plugin that uses full-text indexing to locate posts that are ‘related’ to other posts.
Get all of my permalink URIs to match up with those created by WP. Oh wait, MT no longer requires you to specify an extension and now lets you use hyphens instead of underscores to separate words. 🙂 In years past this could only be accomplished with a few plugins and some ingenuity (see Future-proof your URIs). Also, since I’m keeping the hyphens, there’s no need to create .htaccess rules for every single post, something I had to do when initially moving to WP (see Maintaining URIs between Movable Type and WordPress).

OK, so this list is getting out of control. I can think of 20 more things to add, but I’m going to stop myself as this post is already 10x longer than it should be.

Another note about importing

I went into detail in the last post about the trouble with importing, but failed to mention the issue of categories. The WP plugin I linked to in that post (and, subsequently, my modified version) doesn’t handle categories too well. In fact, it barely handles them at all. The problem is two-fold.

First of all, the MT import format accepts both a primary category and multiple sub-categories. The export plugin only accounts for sub-categories and doesn’t create a primary category element at all, but it seems that MT falls back to that anyway if no primary is specified; in other words, when no primary is given it uses the first sub-category it sees for that post as the primary category.

Second of all, I use categories fairly sparingly and don’t currently use sub-categories at all. I use one category to separate the linked-list posts from the regular posts (so that I can style them differently on the index and individual archive pages), one for the posts linked to on the bottom of the projects page, and one to specify what should be displayed on the tour. As it stands now, the export plugin only creates a single sub-category entry in the export file and fills it with the first category it finds in the database for that particular post.

The problem then, is that posts in multiple categories (e.g., a single post that is on both the tour page and the project page) lose all but one of their categories in the move, which puts me in the position of having to add those categories back in the MT system.

Two solutions

One option would be to rewrite the category routine of the WP export plugin to account for multiple categories and to place them in the format MT likes. While certainly doable, it may be a bit more trouble for me than it’s worth in light of my sparing use of categories.

It might actually be easier for me to simply re-categorize the posts. In WP my linked-list posts and regular posts are part of the same weblog (I just style them differently), but in MT I think I’ll probably want them to be separate weblogs entirely (and I’ll just splice them together on the main page). Given that the posts in my linked-list category are in that category alone (i.e., not General and linked-list), I can simply pull up those posts in the General category and delete them. Then, I can export from MT and save that file as my linked-list posts (already in an importable format).

After that’s done, I’ll re-import the original export file and then filter for the linked-list posts this time. After deleting those posts I’m left with my regular entries, which I can then further categorize/tag for the tour and project pages (this can be done simply by eyeballing those pages as they are now and checking off the respective posts).

Is there anything left to say?

There’s always more to say. 🙂 However, if there is a part four to this series it will likely be a comparison of the two systems (something I’ve been requested to write by more than a few people looking to break into this whole weblogging thing) and not so much a line-by-line transcription of what I’ve done or am planning to do regarding the possible migration.

FOOTNOTES

My experience with their processor restrictions is somewhat limited. The only time I’ve ever had trouble with CPU time was when I used to have a public referrers page, which was getting spammed to all hell. After locating the problem, removing the public referrers, and setting up some .htaccess rules to keep the spammers from causing every hit to be routed through WP’s system, the problem was resolved and DH stopped sending me automated e-mails telling me that I was over my processor quota. ↩