I think it’s been more than a year now since I switched from Movable Type as my primary content store.

For more than a decade, I would treat Movable Type as a repository. It would handle search and syndication, but the presentation layer would be built by me with a PHP framework, most recently CodeIgniter. It’s an architectural decision I made in the days of Movable Type 2.5, when its schema wasn’t as robust as my demands required.

Fast forward to the present day when I took a job that required me to support WordPress and Drupal, and I knew nothing of these systems.

I had also been feeling disenchanted with my setup. I wanted to spend more time creating content than maintaining the system to manage it, and the few customizations made to my Movable Type installation became daunting as my PERL skills have atrophied.

So I adopted WordPress as a blogging platform and deployed Drupal for my music projects.

They’ve been working out well so far, and the crash course in getting them running certainly helped in the office.

As a user, I rather like the WordPress interface. It’s intuitive and feels speedy.

Because I limited what Movable Type could do with my content, I had to lock the configuration of my installation to practices of a specific era, namely the early 2000s. As a result, I had to use the “Convert line breaks” option when editing entries, even as the rich-text editor improved with each upgrade.

Letting go of those requirements felt liberating. I didn’t have to think in code and  content.

The same can’t be said about Drupal. Content editing still runs on that limited formatting paradigm of automatic line break conversion.

I also perceive a bit of a speed advantage in the WordPress UI, but part of that perception is colored by my experiences with PERL. I just know when I click a button, I’m far more impatient for a result from Movable Type than from WordPress. Drupal’s responsiveness sometimes makes Movable Type feel sleek.

So I must not like Drupal, then. Not so fast.

Critics of the PHP language like to use WordPress as a strawman for the kind of ugly code PHP makes possible. I created two themes for WordPress, and working in the global namespace after years of MVC development goes against muscle memory.

Drupal 7 is also developed in the global namespace, but it’s naming conventions are so strict, they pretty much emulate object-oriented programming. Emulate, yes, but it’s not the same thing. Drupal and WordPress both have deep documentation, but Drupal has far better readability.

Drupal is also very good with customized content. Sure, it’s possible to hack WordPress to do something it wasn’t designed to do, but Drupal accommodates those kinds of hacks at the outset, often through its own user interface.

In the case of my music projects, I had an existing database keeping track of my albums and tracks. I could have refashioned that data as custom Drupal fields. Instead, I created a module that would communicate with that external database.

Could Movable Type have done the same thing? Eventually yes it did but not at the time I needed it to do so.

As an engineer, I would much better prefer to work in Drupal’s highly-structured environment, but as a user, WordPress does a far better job getting my thoughts into pixels.