On October 4, 2009 by mariya said:
http://www.robozen.com/drupal-sucks/
- Drupal Sucks
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.
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?
And on October 24, 2012 ( three years later) she said:
- Does Drupal Still Suck?
http://www.robozen.com/does-drupal-still-suck/
It’s been more than three years since I published my post Drupal Sucks, igniting a flame war of epic proportions. The sweet irony is that I’ve been doing almost nothing but Drupal development since. The post got so much traction that, despite my opinion, numerous clients have asked me to help with their own Drupal-related niggles. A few years of experience and a couple enterprise sites later, has my opinion changed?
In a word: no.
Does Drupal still suck? Yes.
I’ve learned to work around Drupal’s shortcomings, and to describe them with more accurate terms. But my initial impression – that Drupal is a bloated and poorly-designed system – still stands. Here’s an updated and better-informed list of reasons why.
Jack of all trades, master of none
For most users, Drupal is too difficult to use out of the box – WordPress, for example, is much simpler to set up and configure if you’re not a developer.
But Drupal has frills that are unnecessary for the techies that seem to use them the most. The interfaces for configuring Views and Panels, for instance, seem to only be used by developers. So why not replace the infamous “click monkey” UI’s with an elegant DSL?
Drupal lets you “build from the roof down” – it provides everything out of the box, often poorly implemented, and then requires developers to tear the building apart just to install a new sink. Take the default markup spewed out by views, panels and blocks. It’s terrible, bordering on unusable. If I had a nickel for every time I had to click a “no markup” checkbox I could afford never working with Drupal again. Why not make the sensible assumption that the people who configure these elements know basic HTML, and design a system where “no markup” is the default until the developer *writes* some markup?
Configuring the platform – or “Drupal development” as it’s known – seems to be mostly working around these infuriating defaults. Drupal tries to be friendly for users of all technical abilities, and fails to be user-friendly for any specific group.
Poor Support for Version Control and Collaboration
Yes, I understand how Drupal Features works. Once you’re done being a click monkey, you use a module called Features to export the configuration to files, which you can then check into Git or Subversion. When you check out that feature on production, you “revert” it in the production database so it matches the latest code.
But the process for updating a feature is very awkward if you’re working with multiple developers and environments. Say you have a feature “foo” that contains a view. To add a new field to that view you:
Click around the Views interface to add the field you need. Save.
Go to the Features UI to download a fresh export of foo.zip
Unzip foo.zip
Copy the contents of foo to your custom modules directory, overwriting the old foo files. Commit.
Deploy that code to your production server.
Go to the Features UI on the production server to “revert” the feature foo. (Nb. if you think about it, “reverting” actually means “updating”. Intuitive, huh?)
Notify all the other developers on the project that they must revert foo to avoid conflicts with the versions in their own databases.
Compare that with changing a view in Rails or Symfony:
Update a template.
Check it in.
Deploy.
Have a beer. (Any changes made by other developers will get merged in by version control, so no one needs to be notified.)
Yet, as much as I dislike Features, it seems to be the only reasonable way to work in Drupal. And to add insult to injury – Features isn’t even bundled into Drupal core. It’s a contrib module.
No Dependencies Management
If you use a framework with a good dependency manager, you don’t have to check core code into your repository. A fresh Ruby on Rails app, for instance, is a barebones directory for your custom code, plus a few config files. All the contrib code you need is listed in your Gemfile, and those items – including Rails itself – are automatically installed whenever you deploy.
Drupal, on the other hand, has no such separation. Your Drupal installation *is* core code, with a directory for your custom modules living inside it. Unless you want to devote some days to intense bash scripting, you typically have to pull the entire codebase plus all your contrib modules into version control.
Hideous Unreadable Spaghetti, Terrible Data Modeling
When I complain that Drupal is difficult to develop for and to debug, fanboys respond “Learn 2 Droople, k”. But that’s missing the point.
An elegant framework can be easily understood by reading the source code. The same just cannot be said of Drupal. It’s a labyrinth of hooks, many of which accept a single mystery parameter $variables – and it’s impossible to know what those variables are with a quick glance at the function signature.
In fact, just about everything in Drupal is stored in arbitrarily structured nested arrays. Not even objects are stored as objects. Custom data types, for example, are stored and passed around as arrays. As a result, CCK is very limited. There is no inheritance, no has-many support, no way to elegantly share fields between different types.
I’m not saying that development should be easy. But it took me less than a year to get comfortable with the Rails and Symfony frameworks, because they make sense. They are minimalistic and elegant by default. Yet years later, I’m still learning to navigate around all the pitfalls that Drupal has laid out, and a day of coding without API docs is unthinkable.
The Future
I don’t think Drupal is unredeemable. Drupal enables you to quickly get CMS capability, themes, and tons of other features that we know and love.
Most importantly, it pays my bills.
And because it might continue to pay my bills, I hope it takes a turn in a less awful direction. Drupal 7 has made some improvements, and I’m eager to see what Drupal 8 has to offer. Solving some ongoing performance and caching issues will help, and the inclusion of Composer (the PHP equivalent of Bundler) sounds amazing.
Most promising is the move to use the Symfony2 core. I’m a big Symfony fan and a good number of my gripes with Drupal will vanish if it transitions to a more object-oriented, build-from-the-ground-up approach.
But hey, that will bring me to another reason I hate Drupal – its utter lack of compatibility between versions. I’ll be very pleasantly surprised if the upgrade from Drupal 7 to 8 will be any less painful than the previous ones have been. So bring it, Drupal 8! Looking forward to my clients calling me back for help with yet another complete overhaul.