Once upon a time, before the advent of the “blog”, I wrote a content management system. It had a few features: text formatting, file uploads, discussion forums. It wasn’t buggy, per se, but it had its quirks, and at most it had 20-30 administrative users through its entire life cycle. It’s a tragic folly how many hours I invested for each of those users!
Compare this to Drupal: more than 10,000 developers have contributed, and it’s in use on over 500,000 sites. Development is passionate and sustained, and security updates are released regularly. It seems like Drupal is only accelerating, in terms of public awareness and the profile of sites running Drupal (whitehouse.gov being an oft-cited example).
I’ve advocated for Drupal for these reasons, and others as well. Drupal core and its contributed modules provide a lot of functionality out of the box: from user accounts and permissions to custom content types to, well, a lot of stuff. The language of Drupal, PHP, is available on almost every hosting environment and is comparatively fast and easy to scale (I don’t mean to start any fights about this, and obviously the speed a parser executes can’t overcome all poorly written code). I’m committed to open source software, and contributing back to a community that sustains my work is personally fulfilling.
However, from the beginning, I’ve found myself struggling against Drupal. When I started out, it took me a while to discover there was a “right way” to work with Drupal, because so many of the examples I found were what I’d charitably describe as hacks, and it seemed that Drupal was a system that was designed to be used in a clumsy series of kludges in which the ends justify the means. (Before I learned anything else about Drupal, I learned this: if you’re looking for a feature, it’s probably not a good idea to use the module with the obvious name. Image? Event? Twitter? Nope.) Ever since I realized there was an underlying logic to Drupal, I’ve been locked in a series of intractable submission holds, attempting to wring elegant solutions from my work with Drupal.
Some accomplishments I’m proud of. Working with the Patterns module to move more configuration into the filesystem has been satisfying, and it’s great to not even consider checking a database dump into version control in order to collaborate on development of a Drupal site. (Some have used the module update system to achieve the same effect, putting configuration in PHP to be executed via update.php once another developer pulls the code.) However, even this example is bittersweet: the Patterns module remains tragically incomplete, and it’s disappointing that there’s no clean way to share configuration changes across a development team. When I think about ActiveRecord migrations (from Ruby on Rails) by comparison, honestly, I get a little emotional.
Most of my struggles (and my team’s struggles) have more to do with user experience. Once the initial feature list is satisfied by enabling the right modules, hours of work invariably follow to harmonize the display of the content with the rest of the site, to integrate the administrative interface for the features from contributed modules, and to disable (sometimes by extreme measures) interface cruft and unnecessary features that come along for the ride. I really believed, when I started with Drupal, that the commitment of a large number of developers would bring contributed modules into conformity with user interface expectations, and that Drupal would become dramatically more sensible for administrative users and developers.
To be fair: that has happened. A little. There’s been significant work on Drupal core to reduce the confusion users face when they look at the administrative pages. When you install Drupal 7 with no contributed modules, it’s pretty lovely to behold. But even without a proliferation of modules (or “features”, the abstraction that collects modules to be installed as a group) there are core problems that create unneeded cognitive load, such as the differentiation of “Menus” from “Content” and “Views”. As a developer, I understand why these are separate entities, but not why it’s the user’s responsibility to maintain their own mental model for what you might call “Site Structure”. Drupal still seems like a collection of developer-facing concepts lacking a user-centered conceptual framework. And as someone who really cares about user experience, it pains me deeply to have explained away this failing for so long.
In fact, I have recently stumbled on an uncomfortable truth, especially so for a committed long-time advocate. I hate Drupal.
I’m not a hater, generally. I don’t hate foods, or movies, or music. Some things I think are really bad: bad taste, bad execution, etc. But no one’s forcing them on me, so I can pass judgement and move on. No need for hate. But what I feel now is that bitter hatred that wells up in the final days or weeks of an abusive relationship, the gut-wrenching twist when you get a glimpse of yourself from another perspective, the sickening awakening to inverted love.
And I loved Drupal. I really wanted to nurture what we had together. I thought: I know Drupal hurts me - but if I work really hard, and give my very best, maybe Drupal will change. That kept things going, for years. But then I started to come around. I realized that Drupal didn’t give me that Forms API because Drupal loves me. I realized that ignoring me unless I named a (global) function with exactly the right prefix wasn’t just frustrating, it was killing my joy in the work that I do. And I realized, that, essentially, Drupal will not change.
It’s not that the core maintainers don’t want to make a better product - they’re working constantly to do so. It’s that, despite declaring that Drupal eschews backward compatibility between major versions, fixing what’s broken (and I use that word broadly, I know) would alienate too many users and module maintainers. The incremental changes in Drupal 7, while sufficient to break backward compatibility, are insufficient to fix the primary conceptual and functional problems as I see them (it’s tempting to start listing them all here, but that’s for another post). For me to not hate Drupal, much of core would need to essentially start over.
I know it’s not reasonable to expect a successful project to radically reinvent itself, even if I believe it should. So the only rational thing I can do is cut my losses and start making plans to move on.
This could be the kind of article that starts a heated discussion about “right” and “wrong” ways of doing things, but I really hope that it doesn’t. I don’t mean to make the case that you should hate Drupal, or that, if you do hate Drupal, you should stop using it. I’ll still be using Drupal in the future, but I’ll be much more circumspect in choosing it as a framework, first asking: Can this be done in Wordpress? Should this be done in Rails? Every project needs to be evaluated in light of Drupal’s productivity tax, and for me the bar for what makes Drupal a good fit has become considerably higher.
Thank you, Drupal. I wouldn’t be where I am without you. On the other hand, of course, I wouldn’t be where I am without you.