Edit (October 26, 2012): This post is out of date. Please read and comment on my latest post Does Drupal Still Suck?
Are you choosing a Content Management System for your next site? Allow me to throw in my two cents against Drupal. In theory, Drupal is a CMS that lets you control your site out of the box. In practice, it’s a nightmare to configure and maintain.
I recognize that Drupal might work for small sites: install the software, upload your custom theme, and start adding content. But if you’re planning a serious site, with custom features and potential for high traffic, Droople, as I’ve christened it, might not be your best bet.
Apologists may protest that module X or hack Y might fix my gripes with Drupal. I think this is irrelevant. A CMS requiring a slew of third-party mods before it can be usable is useless to someone who can code a custom Rails CMS in a day or two. (Hint, hint. Build it in Rails.)
Without further ado, here is a breakdown of why Drupal is bad for the various parties involved, together with Why It’s Bad (WIB) notes for the less tech-savvy.
Gripe #1: Drupal Stores Just About Everything in the Database
Databases are great for storing passwords, content, and countless other things. These things do not include “views”, i.e. templates. That’s right, templates. In the database. Drupal stores templates in the database.
WIB: Best practices dictate using a version control tool like Subversion or Git which, among other things, lets two developers “download” the same code so they can work on it simultaneously. Unfortunately for Drupal developers, database settings are not typically stored in version control. This means that two developers have no easy way of coordinating their work. Further, it means you’ll have a heck of a time replicating your settings across multiple servers if you have a high-traffic site that requires load balancing, or a staging server where you want to preview changes before they go live.
Another thing Drupal stores in the database? Logs. In the database. Drupal stores logs in the database.
WIB: Logs record visits to your website, together with other useful details like errors. When you get lots of traffic, logs tend to get huge – we’re talking gigs. Logs are important for debugging, but, unless you’re a high-security outfit, they do not need to be permanently stored. If you back up your database regularly – and you should – you’ll be transferring all that unnecessary data every time you run a backup. Further, you might want to grant a sysadmin or programmer access to your logs to help diagnose a problem. You don’t want that person digging around in your database for this information: one bad search query and your data is gone.
Gripe #2: Drupal is Freaking Hard to Use and Has a High Learning Curve
In the good old days, building a website meant coding a page in HTML and uploading it to a server. If you wanted to update the page, you edited the HTML, and re-uploaded the file. Then people who didn’t know HTML started clamoring for a way to edit their own sites. Along came Content Management Systems, presumably to let an admin log in, edit, save, and call it a day.
Enter Drupal. This CMS, my friends, is so bloated that it takes days, if not weeks, for the layperson to learn their way around it. In fact, my Drupal clients are so confused by the interface that they still send me content and ask me to input it for them.
WIB: The whole point of a CMS is enabling a layperson to update a website. I think the average person can learn basic HTML and FTP within weeks. So if a CMS takes weeks to learn, and you still need a techie to help you find your way around it, the CMS is not doing its job of simplifying the website update process.
Why is Drupal so hard to use? It’s a combination of bad usability and confusing navigation. An example of Drupal’s bad usability is requiring a user to confirm changes twice before they’re saved—often with the Save button located below the jump, i.e. out of view. As for confusing navigation: creating a blog post is under “Create Content” but editing a blog post is under “Manage Content” and sidebar content is under “Site Building / Blocks”. What?
Gripe #3: Drupal’s Design is Piss-Poor
Drupal has a history of security vulnerabilities and is written in ugly spaghetti code (guys, have you heard of classes? Objects? Inheritance? Oh, nevermind).
It also has poor maintainability. In other words, upgrading to a newer Drupal version breaks templates and other code you may have written for an older version. Fixing this, of course, costs time and money. Other frameworks also deprecate older APIs, but in my experience, the changes between versions of other frameworks are not so drastic, and there is often a helpful process built in to migrate your code.
Gripe #4: Drupal’s None Too Friendly
There’s been quite a backlash over Drupal’s new trademark policy, which is rather contrary to the spirit of open-source software. Why protect your trademark so fiercely, Drupal? Your product is open, and great, so why the need to protect it against sites like DrupalSucks.com? Oh, right…
Conclusion: Drupal Sucks
If you are on a low budget and do not plan on hiring a developer, give Drupal a whirl (I guess). However, if you find yourself needing an oxymoronic “Drupal programmer” to do extensive configuration, consider hiring a Ruby on Rails developer instead. Chances are, you can get a custom CMS at the same price and with half the frustration.
Edit: Oh, and Drupal’s search also sucks. Thanks YCombinator.
Edit #2: I was unclear re. the templates in the database. I wasn’t referring to .tpl files, but to Drupal Views.
Edit #3: Oh, and for the templates you do store in the filesystem, the naming conventions for overriding a particular item are horrendous. For example, block-block-5.tpl.php contains the auto-generated id in the filename. So if the node/block has a different id in a different environment (dev vs. production) you’re out of luck, and the template won’t work.
Edit #4: Thanks for the amazing feedback everyone, both positive and negative. There have definitely been a lot of helpful suggestions. I’ll look into them all and write a followup with the results!