Take This Type And Move It Dept.

By Serdar Yegulalp on 2013-07-08 14:00:00 No comments

Last year, when I began a complete redesign of this site, I also contemplated a change of publishing platforms -- switching everything from Movable Type, which I've been using since about the mid-2000s to WordPress, the blogging platform that by the makers' own admission powers at least a quarter of the entire web.

I know some other folks who had made that exact switch -- Tim Hall (a/k/a Kalyr) had done it, and he seemed to have garnered good results from it. So I gave it a go. The end result was such a lamentable mess that I went right back to Movable Type and haven't budged since.

(Techno-wonkery ahead.)

The biggest reason for migrating to WordPress (WP for short) was its sheer popularity. Everyone uses it, it's easy to install and maintain, it's got tons of themes and features, it's written in PHP (which, whatever else you want to think about the language, is at least broadly-used and -supported). Yes, and if everyone else jumped off a bridge...

Movable Type (MT for short), is the obverse of it in many ways. Its user base has shrunk as many folks defected to WP; it's not widely supported by third parties; it's written in Perl, which is starting to be seen as a bewhiskered language. Worse, MT's development as of late has been an absolute roller coaster, no thanks to the company and its products having changed owners several times. (A whole foofaraw about the licensing of the product didn't help either; it's now GPLv2.)

So why did WordPress, the likely candidate for the future evolution of this site, turn out to be such a disaster for me? Let me count the ways.

1. Dynamic vs. static publishing.

Both MT and WP offer, through various means, the ability to publish pages on the fly (dynamically), or publish them to static HTML (statically). Most people like the former option because it means that any changes to the site show up immediately, and bloggers are an impatient lot. So if you make some big, normative change to the site, like a new sidebar, you have to republish every single page on the site. Sounds handy.

Here, in my purview, is what's wrong with dynamic publishing. Or, rather, why it's a grossly oversold feature of WP.

First off, the vast majority of blog-type sites don't need dynamic page generation. The number of times people will read a page far outweighs the number of times you ever change it, so it makes sense to simply write the page to HTML and let static page serving -- and caching -- take care of the user load.

A web server has far less trouble serving up 100,000 hits to a static webpage (that's it's job, after all) than it does serving up the same 100,000 hits to a page that is generated dynamically from a database backend. Each such page hit generates a database call, and god help you if you're on shared hosting where the number of simultaneous database connections (which you can't change) is in the single digits. The very strategy used to publish dynamic sites can turn into a way to bring it to a grinding halt if you're not careful.

Now, there's ways to ameliorate that, and I went through a whole plethora of such solutions on the WP sites I was testing out. They typically involved adding plugins to WP, of which there are an astounding array that fulfill every imaginable function. One such caching plugin seemed to do the job: it built pages into a static HTML cache, and served them from there until they were changed.

But after some fiddling with it I realized I was right back where I started. I already had this functionality in MT; moving to WP (itself a major production) wouldn't given me anything I didn't already have. And what's more, the plugin in question was a third-party product -- it wasn't core functionality, and by all accounts the WP team had no intentions of adding static publishing as a core feature. MT has both static and dynamic publishing as core features. Plus, every plugin I added to WP to put in something that wasn't included as core increased the risk of a cross-incompatibility with another plugin, like the car whose snazzy lights only run down the battery all the faster when they're left on by mistake.

Even further, I'd already done quite a bit of work in MT to alleviate the need to rebuild every page on the site in the event of a normative change. Sidebars are SSI includes; ditto headers and footers. Many other elements can be cached internally to MT, which sped global rebuilds when I had to do them. And MT's background queue allowed me to perform a total and silent rebuild of the site by simply pressing a button and forgetting about it. It wasn't like I had to babysit the whole system during the rebuild process, like I had in earlier editions of the program.

So while I wouldn't have to worry about those tedious rebuilds anymore with WP, I had to ask myself: sure, but at what cost to the general stability of the site, front-end and back-? And what had those rebuilds ever really cost me to begin with? Not much. I could rebuild the entire site in ten minutes -- and again, in a totally passive way -- and since the site was built from the most recently-updated pages back to the least, most people would never know anything was happening anyway. The total server load imposed by running MT was rather minute and bursty compared to what WP did to the same server, which was -- more often than not -- to choke it.

Now, I might think differently if I was running a site that had hundreds of thousands of pages on it. But the total time to rebuild the two thousand or so pages on this site is around ten minutes on my current server, so I don't see myself reaching such a stratosphere any time soon. And if I did have a site of that scope, I doubt I would be running it on MT or WP anyway.

2. PHP.

I don't like PHP as a language for a variety of reasons -- it's a tasteless mess of hacks piled on top of hacks, it's loaded with questionable design and security decisions, and it's one of the last platforms I would choose to write a project of any notable size. It's good for quick-and-dirty "duct tape" programming: the image thumbnailer code on this site is a PHP script. But I hate it, and I'd like to replace it with something a little less appalling eventually.

WP is written in PHP, and better people than I have talked about the architectural issues in PHP. But there are other things about this fact which bother me.

MT's templates, which generate the site you're publishing, are written in MT's own markup code. No other program uses this markup. This annoys some people, since they have to learn another language just to write templates in MT, but it has the advantage of being reasonably secure. It's pretty much impossible to mistakenly expose low-level stuff about your site through those templates, let alone break the site entirely.

WP's templates are themselves PHP scripts. This makes it a lot easier for people to write templates for it -- there's far more people that know PHP than know MT in any form -- but it also makes it that much easier to do things that compromise the entire site's security. It's easy enough to be a PHP programmer, which is why a lot of people do it. So easy, I would argue, that you only learn things like good coding practices as an afterthought. Not that such a thing is unique to PHP, but the way most people pick up PHP, by copying and pasting stuff they found lying around on the web, only exacerbates the problem. They have no way of telling if the code they're using is badly written, because they have no experience in evaluating code quality. (I'm not one of those people who thinks programming should be hard, but I do think it should require discipline.)

WP's plugins have the same ominous shadow trailing them. It's easy to write a very powerful plugin, but that also means it's easy to write a plugin which steps on other plugins or, worse, breaks your installation in some way. Combine that with the diffident way in which most people learn PHP, and that explains why when I tested four or five different "global replace" plugins, almost all of them broke when I submitted HTML -- to the point of crashing the WP admin interface -- because they didn't properly escape their inputs, a Web Programming 102 lesson. (To be scrupulously honest, MT isn't immune from this stuff either, but it seems far harder for an MT plugin to be a malicious actor than a WP plugin, and no MT plugin I have dealt with has ever been that shoddy about input fields.)


I would never try to talk other people out of using WP. If it works for them, great -- and I know plenty of people who have it deployed in production environments and get great results with it. But for a variety of reasons -- some technical, some personal -- I'm not one of those people.

I haven't ruled out the possibility that future versions of WP will be better. To be honest, I'm hoping they are, because the rather draggy pace of MT development has me worried about the product becoming to blogging what VMS was to the server world: a legacy product that stopped evolving and stumbled along for years on life support before finally being sent to the abbatoir.

Other possibilities present themselves. The forthcoming Ghost looks interesting, but it needs to run as a Node.js app, which I can't do on my current server, and the emphasis on markdown rather than a rich editor is annoying and presumptuous. Drupal and Joomla! look far too top-heavy for my needs, and most everything else is either too primitive or too poorly supported to be useful.

So, for the time being, I'm stuck with Movable Type. It isn't bad, but as they once said in The Muppet Movie, I hope that something better comes along.

Tags: Movable Type WordPress programming software technology