A couple weeks ago I wrote a post on why customers complain about Drupal -- the short version is that they either had incorrect expectations, or "developers" who were in over their heads. Nothing wrong with Drupal there. There are some very legitimate downsides to Drupal from a technical perspective, however. Here are our top 6, and why they're not enough to keep us from recommending and using Drupal for nearly all our work:

6. Drupal is a total memory hog.

Under the hood, Drupal has a really powerful hook system, which auto-detects and auto-loads functionality. All a developer has to do is follow a specific naming convention, implement a specific hook, and the code gets auto-discovered and called in the appropriate spot. This power comes at a cost -- Drupal has to load every single enabled module on every single request to see if it implements a necessary hook. Since PHP is process-based and doesn't have any long-running threads, this means there's a performance hit.

On low-end commodity hosting, there may not be enough RAM available for the web server to load a large Drupal site. Generally we need to allow PHP to use at least 128MB per request, and on some large sites running lots of modules, even more. If you only have a couple GB of RAM available, you could run out with 20 active requests.

Fortunately, hardware is relatively cheap, and with the various caching strategies we typically use with Drupal, we can get sites speeding along. But this does mean you need quite a bit more hardware to run a large site than you would with a static site or a leaner, more efficient framework.

5. It's PHP.

I actually really like coding in PHP -- it's easy to learn, easy to understand, and pretty powerful. But it has a number of flaws. Historically it has had a slew of security problems due to a bunch of convenience things that went so far as to conveniently include remote code in every request, if you passed a certain GET parameter! These are pretty much a thing of the past -- PHP 5 did away with most of the glaringly easy ways to hack PHP sites. But PHP has kept the reputation for having shoddy security baked in...

I would really call out 2 weaknesses of PHP: no threading/inter-process communication, and very poor Unicode support. Lack of long-running threads, worker threads, or other things along those lines means that a huge percentage of the Drupal framework needs to get loaded on every request -- it can't just sit there in RAM waiting to get called. Drupal does not really have a way of registering functions that implement hooks -- it does cache many of them, but not all.

The Unicode issue almost seems criminal. We've had UTF-8 for way over a decade now, but PHP cannot accurately tell you the length of a Unicode string? This is supposed to be fixed in PHP 6, but for the time being, this means doing much localization work in PHP involves having your own string management functions.

So our assessment: Security issues are no longer worse than most other available languages, caching can mitigate some of the lack of threading (and it does make it a lot easier to program), and Drupal works around the lack of UTF-8 support with its own functions (but why should it have to?).

4. Version wars.

Drupal 7 has been out for 10 months now. Drupal 8 is in development. Drupal 5 is no longer supported. And we're still building most of our sites in Drupal 6. Anybody who has built a Drupal site starts out with the big question: what version should I use?

Drupal 7 isn't yet the slam-dunk answer. The reason? There are still a ton of very useful modules that are not yet available for Drupal 7 -- and many that are not even close.

Drupal 7 is a far better platform to develop on. However, there is so much already done on 6 that we can roll out D6 sites much quicker for our clients, at much lower cost, for all but the most simple brochure sites. We have done 2 D7 sites so far, and over 50 D6. D7 isn't even faster it turns out -- the main reason for going to D7 is that D6 is going to get left behind when D8 gets rolled out -- but at the current rate that's still a couple more years.

Drupal has a horrible reputation for painful upgrades. I would say that's largely an issue of the past -- most module maintainers provide decent upgrade scripts, upgrades tend to happen with no data loss and very little functionality change. But as a highly commercial platform (not proprietary, mind you, just used by lots of businesses) customers need to pay to get modules updated to the new releases, since most of the development of contributed modules is done by companies like Freelock, who get paid to do the work. And as long as it's cheaper to roll out a D6 site, and few other compelling functionality reasons to upgrade to D7, not many clients are willling to foot the bill to get the job done.

3. Abandoned modules

Or worse, modules that get replaced by an entirely different approach.

In the early days of Drupal, most site building was done by people programming custom modules on top of the Form API and the various other parts of the Drupal internals. Enough of these were generalized and shared back to the community that the next phase was characterized by thousands of single-purpose modules -- install exactly what you need for each feature you want to provide, and perhaps need over a hundred on your site.

Now the number of modules you need is getting far less -- we have more general purpose, extremely powerful modules like Views, Rules, Display Suite, Features, and Context. As a result, the single-purpose modules are becoming obsolete, and developers pretty much abandon them.

This is actually a good thing -- these power modules really let a site builder build exactly what they want. But they also each have their own learning curve -- it's not as simple to drop in and turn on the functionality you want, you generally need to configure the behavior you want after installing the power module. This makes the Drupal learning curve even tougher for people who just want a site -- if you don't know how to use the power modules effectively, you can easily get frustrated when you find exactly the module you want -- but it hasn't been updated for 2 years. Or if you've been using a module for years, and it's no longer supported -- and there is no clear upgrade path to something else.

This is where Drupal has turned professional. Site building in Drupal takes a lot of knowledge to do rapidly. And that's not knowledge even the best non-Drupal developers can get quickly -- so much of this knowledge is very specific to Drupal. Knowing which power modules can address the shortcomings of Drupal core, knowing when it's time to drop in a power module, knowing how to use the interface -- these you can figure out. But how do you even know the power module exists?

That's why good Drupal freelancers and shops are expensive -- they're in demand, and they can do amazing things very quickly. We may have a high rate, but we know how to get the job done...

2. Caching

Caching in Drupal is perhaps the biggest thing that mitigates the memory hogging, the performance issues, and so much more, making Drupal as fast as most any other platform out there. But it's also a curse.

In short, if your Drupal site is misbehaving, a surprising number of times clearing the cache fixes it. Drupal caches things at a lot of levels: during a request it caches every node it loads. The menu/URL system that drives every request is cached. Blocks and pages can be cached -- but by the time you reach the page level, you can no longer use caching if you have anything personalized on the page (such as shopping cart contents). Drupal also combines javascript and css into compact files.

Then there's system caching. We run a PHP opcode cache to get more out of PHP. We tune MySQL so that most of the database is cached in RAM. On some sites we set up file-based caches to skip Drupal entirely, or set up reverse proxies. And then there's Memcache for yet another layer of caching.

The problem with caching is making sure it gets regenerated when something changes. Generally the system is pretty good about clearing out changed data, but there are definitely lots of cases where this doesn't happen correctly.

Caching is really a band-aid for the poor performance of Drupal, the dark side of having so much programmer power. The upside is that it works surprisingly well, and makes Drupal competitive. But it takes knowledgeable system administration to get the maximum performance, or to scale to handle large traffic loads. And it is a source of quirkiness, a bit of an X-factor that can make problems harder to identify and locate.

1. "Drupal Developers"

How do you know if you've found a good Drupal developer? Lots of people claim to develop in Drupal, but there's a huge range in the quality of the result you get, and it's very hard to tell without working with somebody a while whether they know the platform well, or whether they're going to be learning at your expense.

We are all going to be learning at your expense. Development is about solving problems -- once they've been solved, they don't need further development! This is largely a question of experience, but I think there's an element of talent as well -- the talent to see where the crux of a problem lies, and be able to sniff out the heart of the matter. That's a talent, but more important is experience. We have learned a ton by making mistakes. We know how to roll out changes to production sites without breaking them (or at least keeping the broken time minimal). We know how to undo our changes if something goes awry. And things go awry in complicated systems more often than we would like. Experience has taught us to build systems to protect every move, much like a rock climber scaling a tough wall -- while there are a few "rock star" climbers who may free-solo El Capitan, most people who attempt that end up dead. Smart climbers use protection so that if they make a mistake, the rope stops their fall.

Making changes in sites that are already live is quite similar, and to do this smoothly, the protections need to be there from the start -- you don't scale half the wall before putting on your harness and trying to find your ropes.

The problem with inexperienced Drupal developers is they don't know how to protect themselves from the future. In Drupal circles, there's a phrase "killing kittens" -- if you're modifying Drupal core code, that's what you're doing -- something terrible. And the reason is that the next upgrade will clobber your changes. There are safe ways of changing just about anything you need to do -- but "Drupal developers" who are just trying to get your site launched and don't care about long term consequences don't bother with doing it correctly.

A lot of our business comes from cleaning up the messes left by developers who did not build in a future-proof way.

 

That's our list... do you have any others? Can we help you out of a jam from one of the above? Please comment below -- we moderate comments to keep out the spam, so it might be a few days before we post it, but if you're leaving something constructive it will show up.

Share this article with your friends!

Comments (214)

Code Subsidy

The developers have totally run amok.

24 May, 2018
Drupal Is Not …

Stop Writing So Much F***ing Code. Give me a TURNKEY system that accomplishes something with just some standard HTML theming and a bit of tweaking and doesn't change so effing much, look at tiny little unknown project Scout CWIS for example. WordPress sucks in this respect too. Both WP and Drupal are only used to fund professional coders and an professional specialization and job market, not to actually deliver something of value that isn't an eroded pile of sh*t at the end of the day where it's not possible to tell the difference between an easy task or a hard task, ever, because you are swimming in raw sewage.

01 Aug, 2018
DRC

Today is Feb 2nd, 2019 as I make my comment. WordPress has almost 60% market share now. I don’t think that’s any accident or any less “professional “. I agree with every point the author makes, aside from continuing to use Drupal. And what’s also worth noting is this article was authored back in 2012 but still true today. And now, as of late 2018 Drupal only enjoys a 5.9% market share. As the WordPress user experience continues to improve as it has (and it’s already a pleasure to use), there will be even wider adoption.

02 Feb, 2019

It really depends on what you're trying to accomplish with the site. We support several WordPress sites now, and with the changes around making Gutenberg the default editor and deprecating the classic editor, WordPress is heading in the direction of being a layout builder like so many SaaS platforms.

Drupal, meanwhile, remains a much better solution for managing lots of content. Are you trying to build small, graphically beautiful sites, or lots and lots of content (or other data, like products, employee directories, event management, ?) WordPress has solutions for all of these, of course, but as soon as you get away from core page building, you're talking about a much smaller set of sites, and you're starting to get into Drupal's strengths.

Drupal 8 today addresses pretty much all of my original criticisms, so in most ways, I would say this article no longer applies.

But I disagree that WP is going to continue to expand -- we're seeing a trend back to hand-built sites, with heavy front end development in React or Vue, and a move away from sites where you browse from page to page to more fluid, "cinematic" experiences. In many ways both WordPress and Drupal might see some decline -- although making them "headless" and used as a content repository makes a huge amount of sense -- and this is where WordPress's direction might not be as good a way to go...

02 Feb, 2019
DRC

Disagree all you want. The very message I got in my inbox had all kinds of formatting issues, making it difficult to read. Oh sure, as a developer, you can fix that for sure. But that’s partly my point. Developers love Drupal but the rest of us do not. And yes, WP is indeed taking off and is indeed much more than a blogging platform. And indeed is just fine for managing large amounts of content. And these entities seem to feel the same: https://www.wpbeginner.com/showcase/40-most-notable-big-name-brands-tha…. And finally, I’m having difficulty even posting this message. Your captcha seems to be having problems. WP right out of the box would work feline in this situation too, even if using an old version.

02 Feb, 2019
DRC

Also, you should view what this message thread looks like on mobile. Very difficult to read.

02 Feb, 2019

Everything has its pros & cons, however there are few features which Drupal needed to get fixed like their visual effects, array everywhere, performance along with the memory usage. Also not agree with one of the point which you mentioned for e-commerce as e-commerce industry is growing rapidly.

02 May, 2019
sss

I think you should consider reviewing your article. ;)

08 May, 2019
Anonymous

Definition of Drupal: worst piece of code ever written.

31 Oct, 2019
karthik

Wordpress sucks if you build a large application, wordpress can be used just for blogging, simple website , if you want to build portal that is something more stable, scalabe and strong System, then you should go with Drupal, Wordpress plugin sucks... Drupal modules are free , stablised, reviewed, standard in terms of quality, wordpress plugin breaks in between even the paid plugins are breaks and sucks in between

06 Feb, 2020
Anonymous

I often see/hear the same comment "by being an experienced Drupal developer you'll develop websites way faster than using other tools, frameworks and such".

I ask you: At which cost?

I've known people who work with Drupal for over 5 years that still can't develop that fast.

That's for one simple reason: Drupal is HARD. It's hard to learn about many modules, test them, integrate them, have experience from lots of sites using those. Sometimes we even have to "guess" certain modules' behaviors to be able to use them properly, without having to write custom code.

Oh, and when you have no option but to write custom code, you also take ages, IF you wanna learn the right way, and not just be a copy-'n-paste developer. By right way I mean making sure you follow the standards, future proof, write a well-documented code, focus on modularity, reusability, UI/UX, etc.

Drupal 8 came in to facilitate some of the process, but Symfony introducted another level of complexity, which we are forced to learn as well.

It's an occupational hazard, and I can't really believe it's faster to spend several years to only learn Drupal, through the ways the article describes, that is, mistakes, module issues, the community, patches and whatnot, than to quickly learn a stable framework and develop something from scratch.

Not to mention that the current Drupal framework is high-level to an extent of accustoming developers to "easy" coding. They actually become lazy developers, if they were already not ones.

The real challenges Drupal offers are modules integrations, racking one's brains with their/core bugs and having to learn "Drupal-way" abstractions of what should be easy and low-level for developers.

28 Oct, 2020
2021

If you can afford an in-house team of engineers to implement Drupal, then why would you torture yourselves by using the Wordpress codebase instead? You wouldn't. OTOH, if you can't afford a team then your site gets sucked in the Wordpress vortex and you inherit a different set of problems, whatever they happen to be, which is different than the problem of the mundane being ridiculously expensive.

12 Apr, 2021

Add new comment

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.