Blog /The Case Against Drupal

November 15, 2010 22:19 +0000  |  Drupal Programming Software 14

I've been doing Drupal development on-and off for nearly three years now and it's always been frustrating. I'm a pretty vocal and animated kind of person too, so my co-workers soon came to know me as the anti-Drupal guy, which can be pretty rough when your employer has chosen to standardise on the platform. Now that I'm finally out of the Drupal world, I wanted to write a little about the platform, specifically speaking to its weaknesses and failures.

My hope here is two fold: (a) that this post serve as a means of communicating to the thousands of frustrated developers out there that they're not alone in their pain, and (b) that perhaps some of this post will help development shops choose Drupal where appropriate and other technologies when it is not.

For the Drupal fan(girl|boy)s, I ask only that you try to read this with an open and constructive mind. While I may rant and curse about Drupal in my Twitter feed, I've tried very hard to make this an unemotional, hopefully useful post about something I've spent a lot of time thinking about and working with.

Drupal Centricism

Drupal Ideology

It seems to be a mantra within the community: "You don't even need to write code". The Drupal ideology is user-centric, choosing ease-of-use over performance at every turn. There's nothing wrong with this of course, so long as your goal is to let unskilled people make websites. However if your priority is a performant application capable of handling a lot of traffic, you're going to have a number of problems.

Some examples of prioritising user-focus over performance:

  • Silent failures are the bane of any developer's existence. It's important to know when a variable isn't defined, or that writing a record to the database failed, or that a file didn't upload properly. Drupal suppresses such messages by default, and as a result nearly every contrib module in the community is so riddled with errors and warnings that development with these messages enabled is near impossible.
  • Views, the de-facto standard way to store and retrieve data from your database, writes queries to the database, so that in order to perform a query against the database, you must first fetch the query from the database. Similar inefficiencies can be found in other "standard" modules like CCK and Panels.
  • Drupal relies almost entirely on caching in order to function at all. Without caching, a method usually reserved for high to extreme traffic situations, Drupal can't handle even a small number of concurrent visitors. Indeed, some projects I've seen have taken more than 10minutes to load a single page, even in development where there was only one connection in use.

Drupal Magic

It's a term celebrated by many in the community. The idea being that Drupal does a mountain of work for you, so you don't have to worry about it. The only problem is that when you're trying to build a finely-tuned application, most of this magic either gets in the way, or even works against you. You get 80% of the way there with Drupal and its contrib modules, and then spend three months fighting the whole application, undoing the damage it's done, just to get what you need out of your website.

The hook-dependent system requires and fosters this anti-pattern. Re-using code often means unpredictable, site-wide changes. A property is written in module X, overwritten in module Y, and altogether removed in module Z, and there's no way to be certain that these functions will execute in a predictable order.

This problem is notably worse when it comes to new developers on a project, since they will undoubtedly not be privy to the magic that is running under the hood, and will have a difficult time discovering it on their own. To those who will answer this with "the project simply needs better documentation", I respectfully suggest that a good code base is easy to understand, and doesn't require a manual that is usually out of date.

To work with Drupal Magic is to attempt to produce useful code against an unordered, uncontrolled, grep-to-find-what-is-going-on-dependent architecture.

Drupal Community

For all the victories in community engagement Drupal has achieved (a massive, diverse and engaged membership), it's the glaring failures that make the whole project a miserable situation for developers. I've already mentioned the standardising on inefficient modules, but I haven't talked about the mountains of really horribly written code yet. Drupal Core, for what it does, is pretty efficient, but too many contrib modules are written by inexperienced developers, or are simply incapable of scaling to enterprise-level capacity. The result of this is that non-developers (managers, sometimes even clients) will point to the functionality of module X and insist: "don't redesign the wheel, just use that", and you spend the next three weeks trying to work around the poor design of said module, eventually being forced to write garbage that talks to garbage.

Often the perceived strength of the community is Drupal's greatest weakness. Drupal is promoted based on its theoretically infinite feature set, but the reality is that in order to use every one of those contrib modules in your site, the memory footprint will be massive, the stability suspect, and the performance abysmal. And gods help you if you try this on a site with millions of users or a similar number of content nodes.

Drupal Establishment

None of this is a problem however if Drupal is used where its features and shortcomings are both understood and accepted as the nature of the platform. Drupal is a great tool in some situations and a horrible burden in others. Sadly, this has not yet sunk in with many of the decision-makers in the web development community. Drupal is being used and promoted as a solution hammer, with every potential development project, a Drupal-shaped nail.

This has a number of negative outcomes, the most dangerous of which is a lack of skill diversity in developers. Companies that insist on Drupal-centric development are in fact promoting ignorance of alternatives that might do a better job and that hurts everyone. Unless developers at these companies take it upon themselves to spend time outside of their 8-12 hour work day to write code for a different platform or language, this Drupal dependency will force their non-Drupal skills to atrophy, limiting their ability to produce good code in the future.


I'm finally at the end of my admittedly unenthusiastic involvement in the Drupal community. Whether the Drupal shops out there read this isn't really up to me, but I hope that this manages to help some people re-evaluate their devotion to the platform. Comments are welcome, so long as they're constructive (I moderate everything), but I'm not going to get into a shouting match on the Internet. If you think I'm wrong, we can talk about it in 5 years.


16 Nov 2010, 12:13 a.m.  | 

Views, the de-facto standard way to store and retrieve data from your database, writes queries to the database, so that in order to perform a query against the database, you must first fetch the query from the database. Similar inefficiencies can be found in other "standard" modules like CCK and Panels.

It's difficult to read this with an open mind when it was clearly written from...well, the word I wanted to use here was ignorance, but that's not right. Definitely incorrectness. I'm not sure what it means when someone bashes something incorrectly and asks the reader to "keep an open mind" when the author is not speaking with the perspective of an open mind.

Best practice with Views is to export your Views to code, putting all your views in a module on a production site. Yes, it does require a (very fast) query to determine if your view is in the database as an 'override', but that particular database hit is negligible. If such a thing were important to someone, some kind of setting where Views was told to assume that all its Views were in the database and never look in the database at all would go straight to the code views.

Of course, this isn't as awesome as you might think, because of the nature of PHP itself. Reading code from the disk and parsing it isn't necessarily faster than reading objects from the database, it turns out, especially when you end up reading a lot of code you don't actually need. Go figure.

And lastly, your major point here isn't really a weakness or a flaw in the system at all, it's a question of philosophy. Your philosophy clearly puts you in the "code is better, code is better" camp. When you have that fundamental philosophy, Drupal will always fail. So will all of the other popular CMSes out there. But some of the web frameworks like Django or Symfony or CakePHP will suit you better. They, of course, all have their own shortcomings and you will trade one set for another.

That's great, but one of the reasons Drupal's popularity has soared is that you can have two tiers of people who manage the site, and that second tier doesn't need to code. (Honestly Drupal is still such that your first tier of site people do need to code. It can't do everything code-free and anyone who says otherwise is drinking too much kool-aid).

Lastly, if you had a Drupal page take 10 minutes to load one page, that site was built and or configured terribly, terribly wrong. One of Drupal's biggest shortcomings is that it's very possible to do things that terribly wrong. But that said, someone did stuff wrong. Not just Drupal.

Anyway, enjoy your anti-Drupal, there sure are problems with the platform and I feel the pain of a lot of them very much. But when you're making your bullet points of what's wrong with the platform, can you please stick to the things that are actually wrong?

16 Nov 2010, 12:33 a.m.  | 

@merlinofchaos, you're right, I suppose I could have gone into more detail regarding the details of Views (my previous employer uses exactly your recommended method mentioned above). You do seem to be missing my point though.

My mentioning of Views/CCK/etc. was there to point out the Drupal ideology that puts ease-of-use by non-developers before performance. This position is as good as any other really, so long as your priority is making the site easy to administer rather than enabling it to endure a mountain of traffic or scream under high load.

Using Views/CCK means adding multiple layers of complexity and load to a process that could have been as simple as running a raw query. My issue is with the assumption that the decision to choose point/click over raw code is a trivial one: it's not. You have to sacrifice performance when you choose Drupal and for many projects that's an unacceptable trade off.

16 Nov 2010, 3:53 a.m.  | 

The incompatibilities between modules was always my biggest problem. I describe our sites as "a house of cards". Adding any additional card could cause the whole works to come tumbling down.

Unfortunately my experience with CMSs (up to 6 now I think) is that they are ALL 90% what you need and 10% fighting tooth and nail for the rest.

Your alternative seems to be to write the code yourself but that's not a solution for someone in my situation.

16 Nov 2010, 2:52 p.m.  | 

My problem with Drupal in a workplace setting boils down to a lack of training programs available.

To maintain and build websites in my old department we used dreamweaver, CSS, sometimes editing the html and using PHP scripted add-ons when neccessary. All these technologies have multiple training programs available - from week long to 1 day courses. This blend of technologies and readily available training worked beautifully to scaffold web work skills as new features were needed for our websites.

However, the department then switched to Drupal and all this stopped working and no training was available. While I'm no stranger to change, my problem with Drupal is that there is no systematic training available and that staff were forced to learn a brand new system, which made most of the functionality they were used to tweaking invisible and inaccessible. As well, if they wanted to become users with more access, etc. there is no training available to facilitate this.

Matt Farina
22 Nov 2010, 3:11 p.m.  | 

@Daniel, I want to share that you are not alone in your criticisms of Drupal. I know a lot of people who think and feel the same way you do. At least the gist of your message.

The problem I've heard is "what CMS do you switch to?" with the requirements for a security team, support services available, etc. The conclusion is Drupal is the best of a not so great list of options. I've talked to a lot of people who feel like you do.

Now, a clean framework is different than a CMS. A lot of times a good framework built solution is a better choice than a CMS.

Larry Garfield
22 Nov 2010, 4:24 p.m.  | 

As others have noted above, some of your points are valid given a certain perspective. Drupal has made many architectural decisions that trade one benefit for another cost, as does every project. Whether that's a good or bad trade off depends on your perspective and needs. I've written about the same subject, more generally, here:

To be sure, I think Drupal has gotten that balance wrong in some places, and I'm trying to coordinate people to help fix them. Drupal is always a work in progress.

There are ways to make a site scream under load. is running Drupal 7 without page caching as a top-500 site on the web without falling over. It can be done, although it's decidedly not trivial. I think Drupal 7 has indeed gone too far in the "flexibility over performance, and let coders figure it out from there" direction. That is something we do need to fix.

That said, merlinofchaos already corrected a number of mis-statements above. There's one more I will add, though. While I hate the answer of "eh, just add caching" as much as the next guy and think it is a cheap cop-out in many cases, it's hardly unique to Drupal. Most serious web frameworks these days do at the very least render caching. Every professional or semi-professional PHP publication recommends caching all over the place. Drupal's caching implementation may or may not be optimal (I'd argue it's not, personally), but it's far from abnormal in the PHP world.

There's *plenty* of things to criticize Drupal for, but let's criticize it accurately. :-)

Larry Garfield
22 Nov 2010, 4:26 p.m.  | 

@Shawna: Lullabot offers extensive Drupal training, via hands-on sessions, videos, books, etc.

True, the learning curve for Drupal is higher than for "just throw some PHP into a Dreamweaver file", but so is the quality of code and resulting security. (Honestly, if I know a site was built that way I run like hell because I know it's insecure, no matter how smart the PHP monkey was on it. And I say that as a former such PHP monkey.)

Damien McKenna
22 Nov 2010, 4:48 p.m.  | 

Daniel, I think your arguments are missing a key point with application development, web or otherwise - if you don't like how something works there's usually another way of doing it that will fit your need better.
* Don't like the ease of use of building a data display using Views? Write the code yourself and stick it in a module.
* Annoyed that someone else's code is unstable or has glaring syntax errors? Submit some patches to help the cause (something I do quite often) or write something yourself.
* Don't like how certain CCK fields work? Write your own code using hook_form_alter() and hook_nodeapi().

I'll expand upon Stephanie's statement - any code you get *from* *someone* *else*, be it open-source or commercial, will be based on compromises & decisions that are different to what you would do, it's just a part of life. The choice for each developer (& development team) is to either custom-write your own system every single time (a waste of time in 99%+ of cases) or get over it and learn how to best use the tools available.

22 Nov 2010, 7:05 p.m.  | 

Yay for discussion! Listen guys, I'm not saying that Drupal sucks. I'm trying to point out that it's not the only way, and it's definitely not the best way to go for a lot of jobs out there. Right tool for the right job, that's all.

I hear you on that one. My feeling on this is that companies choose these CMSs because of the implied powers of their backends. The problem though is always the tradeoff. Sure that point/click interface is pretty awesome, but the performance penalty for using it on the front-end is often too high. Now, if someone pitched using Drupal for administration of a high-load site with a lighter frontend framework pulling from the same db... I might go for that. It depends on the situation.

I've heard a number of people say things like "Site X runs Drupal and they are a Very Big Site". Having not seen what those sites are doing to endure the load, I can't really comment on that. What I can say though is that one such use case was The Onion... until they revealed that they'd been using a heavily modified (hacking core included) version of Drupal 5 for years. Nearly all of the code running that site was custom and it was so unruly that they switched to Django last year. This isn't to say that Django is better than Drupal for all things, but for a high-traffic newsroom, Drupal wasn't a good choice for them... especially given the options available. How fortunate that they had developers with diverse skillsets in their office.

With regard to your comments on caching, I think you missed the point. My problem with Drupal isn't that it uses caching, but that it *depends* on caching. You're right, most frameworks, and most sites (this one included) use caching in one form or another. It's a performance decision made when you find that it's more performant to skip the dynamic creation step. This is a Good Idea. However, if the job you have to do requires a lot of dynamic output, using a site that depends on caching to get anything up may not be your best choice.

I'm going to assume that the angry tone I read there wasn't intentional. I'll go over your points one by one:

Custom queries vs. Views: It's true, this is possible and I've used this method a number of times before. The question I would ask you then is: if you're concerned about the performance of Views, why are you using a CMS dependent on them?

Submit patches to fix shoddy code: I have actually, but that's not the point. You can't make "the case for Drupal" that there's a plethora of 3rd-party modules that get you 80% of the way there if many of those modules introduce instability and slow your code.

Use hooks to fix CCK: CCK uses an inefficient storage methodology (just look at how many left joins used to get a single record) Why would I want to implement a series of hooks to further complicate the process and increase load? CCK is the result of a user-focus, not a performance one. Hooks aren't going to fix that.

Thanks for the dialogue guys, it's nice to see people caring about their profession.

Matt Farina
22 Nov 2010, 7:24 p.m.  | 

@Daniel I think part of the problem is the different use cases. For many clients / projects having a front end system and back end system doesn't make sense. Think of it this way, you have small, medium, and high scale projects.

For the high end projects you having the funding to build a custom system that is smoking fast and tailored for their needs. This is a great place for a framework. Or, even for Drupal as a content management system while the display of the content to the world goes through something else. Or, you could go caching crazy.

For small projects you are talking about shared hosting. In these cases Drupal has a high overhead and is starting to push itself out of this market. According to Dries this market is about 95% of Drupal sites. So, this is a bad thing for Drupal. Sure, Drupal 7 is more powerful than Drupal 6 and Drupal 6 than Drupal 5. But, the performance of each version has gone down and is pushing Drupal out of the shared hosting market.

Then there is the middle of the road market. This is where most of the core developers work daily. This level of client can't afford to write their sites from the ground up. Or, they have been sold that Drupal will do it all. In some cases without any custom code (which is just not true). Or, they are looking for a CMS product with paid support (Acquia). Or, they are looking for a security team because they won't have their own in house devs.

There are a lot of reasons Drupal works in this middle ground. With APC, base caching, and a few tweaks Drupal really works well for these clients.

But, the high end and low end are still suffering. When it comes to performance it comes down to the needs of the clients. Some clients Drupal excels for. Others it doesn't.

Drupal is in the midst of an identity crisis. Who is Drupal for? Everyone in theory. A small portion of sites in practice. I'm hoping Drupal 8 is much better where it is weak in some of these areas.

And, you are right, you loose your non-drupal coding skills if you just do Drupal. And most of the rest of the world does not code the same way so it is easy to get stuck down the Drupal rabbit hole.

22 Nov 2010, 7:50 p.m.  | 

Well it may be out of place for someone like me to suggest a future path for Drupal, but for what it's worth, it sounds to me like a target audience needs to be chosen and developed for. Either that, or fork core altogether into distinct groups with specific goals. Just a thought.

Anyway, it's nice to be able to have this kind of conversation with a Drupal fan like yourself. Thanks for saying hello!

Nick Yeoman
24 Nov 2010, 3:23 a.m.  | 

Your post is awesome!

I use Drupal on a daily bases and it just isn`t up to snuff as other CMSes.

I`m not sure why there are so many fan boys of it, it`s like they have never used anything else and are not willing to learn.

Just know your not alone Dan! There are others who feel the same.

Larry Garfield
24 Nov 2010, 4:41 a.m.  | 

It's not really a response to your post per se, but I thought I'd point you to a recent blog of my own on the "who is Drupal for?" question:

Introspection is what we really need about now. :-)

Web Video Production
8 Jul 2011, 3:55 p.m.  | 

I agree with matt farina - a clean framework is different than a CMS. A lot of times a good framework built solution is a better choice than a CMS.

Post a Comment

Markdown will work here, if you're into that sort of thing.