According to the Drupal Shell site, Drupal is the second most hated CMS platform. I think this sounds a little harsh and digging into the source 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. Still, Drupal had (has!) such 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. 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 |
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 from managing site content. For example, I worked with a top-tier mobile operator in the early 2000s who asked me to build a web-based knowledge management that stored content in Microsoft Access and published static HTML on their intranet using VBA.
When Drupal came along, it captured the entire range of the market. Hobby sites, small businesses, small and large charities, multi-nationals all adopted Drupal because its flexibility.
Features for free
Eventually, my colleague’s insistence overcame my resistance to learning new technology. As you can imagine, 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 great…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 budget 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 are what everyone in the industry aims for. 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 out of the ordinary to spend hours of site rebuilding after one of the module updates took down the site. Which module? Well, you’d have some trial-and-error testing 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 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 support.