Back in April, the Critical Tinkering Network went live with WordPress, arguably the most popular way to get a fully functional website up in the shortest amount of time. WordPress’s origins are as a blogging platform but increasingly it is being used more as a general-purpose CMS (content management system).
Last week I relaunched the site, this time with Drupal. Drupal is another popular CMS. I’ve had extensive experience with both platforms, and varying degrees of experience with about a half a dozen other CMSes. The decision to completely redo the site was not made lightly and you’d think I’d get it right the first time, wouldn’t you? So why the switch?
There is a computer programming design philosophy referred to as convention over configuration. It more or less dictates that the more mundane decisions should be made for you so you can get on with the more important tasks. David Heinemeier Hansson of Ruby on Rails fame referred to it as “Opinionated Software“. When you decide to use a particular development framework, you are implicitly accepting the idioms and idiosyncrasies—like ’em or not—of that framework in order to save on development time.
We could debate endlessly about which CMS is better but I’ll go out on a limb and say that WordPress is the sensible choice for most bloggers precisely because it is optimised for blogging. It works right “out of the box” and WordPress “plugins”—installable extensions that add new features—are also “plug and play”, for the most part anyway. The problem with WordPress is not that it is preconfigured—or “opinionated”—but that it lacks much configurability at all. It’s “hard wired” and, therefore not a CMS for tinkerers.
Now, if I may both rant and rave about Drupal a bit, yes, it does blogging right out of the box, but it doesn’t give you assorted blogosphere goodness like pings and track-backs without the major configuration. Drupal comes largely unconfigured but it least it can be configured. In fact, there are so many configuration options that can be daunting. There is really nothing you can’t do with the right combination of modules (the Drupal equivalent of “plugins”) and some configuration, but the learning curve is steep enough that Drupal experts are very high in demand. It is truly a tinkerer’s platform.
Those of you familiar with Drupal know that, with each major revision of the platform, some significant refactoring takes place, both in the code and the interface. This is well intentioned and in the long run, worthwhile. But it also means you have to relearn things and it can take quite a while before the modules get updated or, in some cases, rewritten completely.
I originally chose WordPress for this site because I did not want to spend a lot of time configuring and, after carefully evaluating the available plugins, was confident that that I could get all the features and functionality I desired. I went live with just the core blog system and then started adding plugins. I quickly became frustrated by the both the lack of configurability and the poor integration of those plugins. That’s when I reluctantly turned my attention to Drupal.
As of this writing Drupal version 7 is stable and ready for prime time, albeit still a bit sparse on some of the documentation. Still, I anguished over the decision to switch. Since I have been working with Drupal since version 4.6 and gone through the hoops of relearning it with each new release, I did not want to go through those hoops again—at least not for this project—and I didn’t want to go through the major configuration I knew would be required to get the site production ready. Ultimately, I had little choice.
So here we stand with my shiny new Drupal site. The worst is over and I am now relatively “fluent” with version 7. But this site is still a work in progress and the tinkering has just begun.
Had problems with either of these two platforms? I’d love to hear from you in the comments below.