According to the Drupal Shell site, Drupal is the second most hated CMS platform. I think this sounds a little harsh. Digging into the source survey on stackoverflow, we find that it’s actually listed as the second most dreaded platform. While perhaps more even-handed, I’m still not at all surprised as a large chunk of my business is made up of people migrating from Drupal to WordPress. To be fair, WordPress fans don’t have much to cheer. Their platform of choice appears as number three of the Content Management Platforms (CMS) listed in the poll. Still, Drupal had (has!) a loyal following so why does it draw out such a reaction from respondents?
First-mover advantage
Let’s take a quick look at the history of the major CMS platforms currently in use. Drupal was, in the first decade of the 2000s, arguably the top CMS for building websites. It had first-mover advantage, having launched as an open source project in 2001—years before its contemporary competitors. Drupal 4 was released in mid-2002 and started appearing on most developers’ radar by around 2004–2005. Its only real competitor was Movable Type which offered simple blogging capability. WordPress was at version 1 in 2004 and was then also more of a blogging tool than a CMS. Magento and Joomla would come around quite a few years later, launching in 2007 and 2009 respectively.
| 2001 | → | Drupal Movable Type |
| 2004 | → | WordPress |
| 2007 | → | Magento |
| 2009 | → | Joomla |
A legacy of custom website generators
I remember my first foray into Drupal development in 2003. A freelancer colleague kept raving about how great it was and that I should give it a try. (Incidentally, he subsequently became very active in the Drupal community and ended up having his theme bundled in with core.) At that time, I’d been hand-coding websites and building custom ‘site generators’. CMS platforms hadn’t taken off so people were coming up with their own solutions for managing site content.
For example, I worked with a top-tier mobile operator in the early 2000s. They asked me to build a web-based knowledge management system that stored content in Microsoft Access and used VBA to publish static HTML. One leading market intelligence agency I worked with at the end of the 1990s had an online customer database. It delivered web pages using Apache modules. We had to code in C++ and query a flat file database to deliver new functionality. That was fun. Imagine having to deal with memory allocation just to output a web page. Just like coding on stone tablets, right?
When PHP appeared on the scene, it rapidly became the preferred way to deliver dynamic web content. PHP simplified web development but people still had to cobble together their own site generators. You’d need to write your own authentication system and all the other things we now take for granted. Developing for the web became easier but you still had to jump through lots of hoops before getting to the interesting work.
It’s not difficult to see why, shortly after release, Drupal captured the entire range of the market: hobby sites; small businesses; small and large charities; multi-nationals. They all adopted Drupal because it so quick and easy to deliver complex features.
Features for free
Eventually, my colleague’s insistence overcame my resistance to learning new technology. I found that Drupal, in comparison to hand-coding from scratch, was an absolute dream. I could now build feature-rich websites with login functionality, CRUD and custom layouts in maybe one-fifth of the time and cost. Like my colleague, I started raving about Drupal and began recommending it to clients and colleagues.
Drupal was, without any doubt, the most powerful website development platform available. Nothing else in the open-source market could touch it. It was also fun building websites with Drupal. You could get instant gratification by installing and playing with the many available modules. Every developer facing a deadline and budget loves Features for Free when the alternative is hours of coding and debugging. Features for Free is fantastic…unless you have to maintain all those features. More on this later.
Similarly, site owners—who often don’t care that much about the technology—loved that their developer could deliver a widgety-thingamajig-feature at a reasonable price. They’d request some functionality and the developer would say, “Yeah, we can do that with Views.” “Yeah, there’s a module for that, no problem.” “Oh, no module for that but we can build one without a huge site overhaul.” It was great until, well…
The Drupal can of worms
Well, fast-forward to 2018 and nearly every Drupal site I encounter is a huge can of worms. Those great Features for Free aren’t so great when the modules have been abandoned. They’re not great when, years after installation, no-one remembers which module controls what and how everything ties together. Sure, documentation and well-commented source code commits are best practice. Perhaps enterprises can afford to maintain a stable of diligent developers. But many sites are cobbled together on a legacy of little to no budget and a revolving door of low-cost developers with varying skills.
Over time, each person adds their own hacks and disappears. No-one willingly runs updates and upgrades because who enjoys having a nervous breakdown? Run an update and risk a WSOD. Spend hours tracking down some obscure, unsupported and misbehaving module that’s absolutely crucial to the way this particular site works…for free? No thanks!
Fully-documented sites and well-specified upgrades is the industry ideal. However, real-life tends to go something like this:
Site owner: Hey, remember that site you built for me a couple of years ago? I’d like to…
Developer: mumble…mumble…upgrade to Drupal 5…mumble…[PRICE]….
Site owner: Hmmm, I’m good for now…kthxsbye…
A couple of years later…Site owner: Hey, this guy built a site for me. I’d like to…
Developer: mumble…mumble…upgrade to Drupal 6…mumble…[PRICE]….
Site owner: [PRICE]???!!! kthxsbye…A couple of years later…
Site owner: Hey, I have this site…
Developer: Erm…Drupal 7…rebuild the site…
Site owner: What???!!! kthxsbye…A couple of years later…
Developer: Oh, how many thousands of monies did you say is burning a hole in your pocket? Because, you know, Drupal 8…
Upgrades and backward compatibility
Of course, poorly documented, buggy and abandoned add-ons are all too common in the WordPress world. The big difference is backward compatibility. WordPress has been great with ensuring problem-free updates: you see core, plugin or theme updates available; you click Update Now; a few seconds (or minutes at most) later you’re done. You can move on with your day and not give it another thought.
In contrast, updating Drupal can ruin your day. (Or night if you’re scheduling the work during off-peak hours.) Drupal updates can go horribly wrong. During the pre-Drupal 8 days, it wasn’t unusual to spend hours of site rebuilding after one of the module updates crashed the site. Which module? Well, you’d have some trial-and-error testing on a series of modules, one-by-one, until you find the culprit. Updating Drupal is often a dreadful experience.
Sensible developers test updates on a development server first, then get the site owner to test on staging before rolling out to live. This is best-practice. Everyone should be following this workflow regardless of the platform. Yes, if there’s money for it. This effort comes at a price and many, if not the majority, of smaller businesses, not-for-profits and hobby sites just don’t have the cash. People have found that WordPress lets them cheat the recommended workflow. If they see updates they just go ahead and do it live because there are rarely any problems.
Core upgrades for major Drupal versions are another level of pain for the site owner. Drupal 6, 7 and 8 are all so different in architecture from previous releases that upgrading essentially means re-building the site from scratch. This is too much to expect for many. No wonder site owners would rather hobble along with their outdated and duct-taped CMS.
The dread
Keeping Drupal up-to-date is expensive for the owner and time-consuming for the developer. Site owners dread to think about the fees. Maintainers dread jumping through hoops just to run simple module updates. Newly hired developers dread what they might find when they peek under the hood.
I started Another Cup of Coffee as a Drupal development shop because it allowed us to offer powerful functionality at a reasonable price. Years later, although I’m no longer in the business of building Drupal sites, I do remember the feeling of dread when time came to tinker with a mature installation. I have every sympathy for those who list Drupal as their second most dreaded platform. It seems that everyone feels The Drupal Dread. Unless of course, they make lots of money from Drupal support.