Drupal vs WordPress: Why there are no objective comparisons

WordPress versus Drupal. Republican versus Democrat. Two debates where the differences seem so broad, people can't even seem to agree upon fundamental facts. Why? Why is it so hard to find an objective, clear comparison of WordPress and Drupal? I've had several people ask this. And I think the difference comes from fundamentally different beliefs about what a website is, how it should work, and even how people can earn a living.

Where we are coming from

At Freelock, we've been working pretty much exclusively with Drupal for the past 8 years. We chose Drupal because, in spite of many flaws and shortcomings, we could deliver pretty much any functionality our clients wanted, faster, better, and with more flexibility and ability to adapt to change than any other platform.

We provide ongoing maintenance services for Drupal, and have a DevOps approach of continuous development, operations, and quality assurance. Recently several of our enterprise clients approached us asking to provide the same great maintenance service for some of their WordPress sites.

We took a look at our automated deployment and testing pipelines, dug into their concerns about having broken updates and solid backups, and realized that without much difficulty, we could build a mostly equivalent WordPress deployment and testing pipeline to our Drupal version, and provide pretty decent support.

Now that that is complete, we have some fresh hands-on experience with some current WordPress sites -- and with it, some unique perspectives on how the two compare.

What is a website?

Here come the gross generalizations!

If you're a WordPress developer, you think a website is a pretty brochure that advertises a business. WordPress is very designer-oriented, making it easy to create any crazy design you might want to implement. WordPress simply plugs in a blog engine and page editing to allow business users to easily create new content and edit page content across their sites. To a designer, everything you need is just another plugin you can deploy -- we don't really want to drill down into the details of anything inside your business beyond the brand, so just find a plugin somebody made that does what you want, install it, and you're off and running.

At least they think it is this easy. And if all you need is a brochure site, it can be this easy. Designers who love WordPress formerly built sites using Dreamweaver, Frontpage, tools that you can hand-edit HTML -- and so just adding the ability for clients to edit their own content is a huge leap forward.

If you're a Drupal developer, however, a website is an information management system. Sure you can do brochures, but what about your products? your events? your staff? customer testimonials? Twenty years ago lots of small businesses built out their operations on Filemaker Pro or Microsoft Access -- Drupal is a web-enabled, unlimited-user, tremendous upgrade of those systems. With an easily themeable face for the public.

If you're a WordPress developer, a website is an editable brochure that is meant to present the brand. If you're a Drupal developer, a website is a collection of content curated and presented to the public in an organized way, with a nice attractive look and feel, and possibly a much more business-critical application on the back end.

If you're a WordPress developer, Drupal is a bloated, complicated, confusing, obtuse monster of a platform, and you don't even know where to start -- where is the HTML that I can just edit?

If you're a Drupal developer, WordPress is an underpowered toy that is mystifyingly popular, with most sites a confusing jumbled poorly-thought-out hot mess under the hood -- what do you mean I have to pay for a module to have a current dev copy?

How should a website work?

I heard a WordPress shop owner tell a business prospect, right in front of me, that you should make an entirely new, fresh website every 4 or 5 years, and looked to me for corroboration. Websites are seen as disposible marketing vehicles that should be recreated regularly to keep current and fresh.

As a Drupal developer, I think the opposite -- a website is a valuable cornerstone of your business, should not be discarded but should be kept fresh all the time, periodically re-skinned, continually improved to provide your business with the most value possible.

If you treat your website as an asset, you can constantly improve it as part of your regular operations and always have something useful for your customers, employees, and other stakeholders, and not go through a big disruption every few years.

If you throw it away every few years, you're creating a nice income stream for your web developers, but you're constantly re-inventing the wheel, continually re-doing things you did the last time around, with major effort and attention needed all around -- by you (the business owner), your designers, and your staff as they have to learn their way around the new site.

Changing look and feel

A fundamental difference between WordPress and Drupal is how easy it is to entirely change the look and feel. In Drupal, a "theme" controls the look and feel, but all of the functionality is embedded in modules, and so when you switch themes, you simply drop the blocks into the appropriate region in the new theme, and you're done -- all your content and functionality is there, with an entirely new theme.

WordPress claims to have similar functionality with themes and plugins -- but in practice, a lot of functionality is embedded directly in the theme. You change themes, and a lot of what may be critical functionality of your site goes away and may need to be added to the new theme by a developer.

So this difference is not one of capability -- it's one of practice. Drupal developers isolate all functionality into modules so the theme is just a skin that can be easily changed. WordPress developers drop PHP snippets into their templates, because it's a fast, easy way to get that functionality there, but then you have to re-do that every time you want to change look and feel. (We do sometimes see Drupal sites apparently built by WordPress developers that follow the WP pattern...)

There are a lot more WordPress themes available, largely because designers are comfortable with WordPress, and that modular, information-architecture-driven approach of Drupal means that creating a nice Drupal theme is harder -- you have to cut everything up into smaller templates.

So at some level you do need to build a whole new site to change the look and feel of a WordPress site -- whereas in Drupal, you could choose a different theme every day without changing how your site works.

Ease of use

Ok, this is a big one. WordPress has a reputation for being "easy to use." After seeing a few WordPress admin areas, I'm left wondering why...

Sure, it's easy to install. So is Drupal. Sure, it's easy to write a blog post or a new page. And the core WordPress standard install does have nice media management built in, and all the basic every day tasks are easy enough. But sites in production with lots of plugins very quickly become extremely confusing, inconsistent, and puzzling -- very far from "easy to use".

Want to change some text that's in a sidebar? You might be able to do that, if it's in a plugin. But you probably need to go back to your designer because it's hard-coded in a template.

Want to slow down the jillions of spam submissions you're getting on your newsletter form? Well, there are dozens of CAPTCHA modules, but most only work on comment forms and user registration -- you need to find one that works with your newsletter plugin, or get a developer to integrate the one you want to use.

Want to create a custom content type? Your developer can do that, if they are actually a developer and know how to code. Or you can add a plugin to manage post types and fields -- but the better ones probably have a subscription, and you'll get nagged when it expires.

You can do it all in WordPress -- but the more you get beyond simple blog posts and pages, the worse the experience gets. You get confusing admin screens, stuff doesn't work across the board, approaches to building the site become fragmented and entirely custom, there are no universal "best practices."

In WordPress, beauty is skin deep -- delve beneath the skin and it gets ugly fast!

Drupal, on the other hand, goes to great lengths to develop patterns that make everything work with everything else. Conflicts do arise, and can be challenging to resolve (just like any complex system) but for the most part, if you choose a captcha system, you can easily apply it to any form on the site, whether it's in core or a contributed module, or even an entirely custom form. When you add a date field to any entity in the system, you can now show it on a calendar. When you create a membership, you can add a price field to make it a product you can add to a cart, add a recurring field to make it auto-renew, add an address field and show it on a map. All without writing any code.

No matter how many additional plugins or modules you add, the Drupal admin area is clean, well organized, and easy to figure out. If you have a complex, powerful site that is supporting a lot of functionality, it's far easier to manage in Drupal than it is in WordPress.

But even managing content on the front end is far easier, and with Drupal 8.2 you can edit most of what you see on any page, sometimes without even leaving the page!

The media management on Drupal 8 has also become excellent, and available right on the page as you edit. But more than anything, Drupal has always had great tools for organizing and managing content -- as you would expect a "Content Management System" to have. In the past, most of these were in add-on "contributed" modules, because many sites don't need them -- for example, scheduling posts to publish at a particular time, setting up a publishing workflow with proof-readers, copy-editors, and other reviews before publishing, arbitrary flags you can set on content to make it easy to keep track of what content has been reviewed and what you still need to go over, for keeping a large body of existing content up-to-date. Many of these are now in Drupal core.

WordPress starts out very easy to use, for very basic uses -- but pretty quickly devolves into a messy, confusing, hard-to-manage mess as you try to do more with the site. Whereas Drupal has historically started out very bare-bones, needing add-on modules to get decent usability, but making it easy to build out in a comparatively organized, consistent fashion, and everything works much more coherently with everything else. And even that has changed in Drupal 8, which ships a much nicer base user experience right out of the box.

If WordPress is easier to use, that's only for one group of users: designers. It's easy for them to get started. It's easy for them to add relatively simple code snippets. It's easy for them to plug it into a sophisticated design. It's easy for them to add plugins, especially if they're not the ones actually using the site.

For site owners and administrators, it's an entirely different story, especially when the site does more than simple blogging. Drupal can get messy if not planned out and built well -- but the standard practices and patterns of Drupal tend to make Drupal sites much better at doing complex things like event registration, e-commerce, CRM, and more than just simple blogging.

Security, Updates, and Reliability

Pasting random snippets of code from the Internet that you don't understand is not necessarily a safe practice. And yet this seems to be a very standard practice among a huge percentage of WordPress "developers". Even if the original author of those code snippets is perfectly honest, chances are good that it's not written in a secure, hardened way. This is part of why we see so many more hacked WordPress sites than Drupal sites.

When a Drupal site gets hacked, it's usually either due to a lame password, or an insecure hosting environment. WordPress is so much more interesting, in a depressing way.

WordPress core, and many plugins, are as secure as anything else, developed with solid programming practices, tested, and fine. The problem goes back to our first question, "what is a website?" and how much non-WordPress code is in so many WordPress sites.

Worse, it seems pretty common practice to develop on production sites, where you can easily break things. WordPress does not make it easy to keep a development or test copy of the site in sync -- when moving a site to another computer, path, or URL, you have to actually do a search and replace inside the database or your site may break in crazy ways.

Many WordPress developers are under the delusion that security updates can and should be done right on production, with the easy update buttons available right in the interface.

As a paranoid, tin-foil-hat-wearing security-conscious developer who expects things to fail now and then, I think that's crazy and foolhardy. What if something goes wrong during the update? What if the update source gets compromised? What if some feature your site depends upon changes? What if the change breaks the layout of your site? How do you roll back if something goes wrong? How do you detect what changed?

Worse, if the website can update its own code, that means an attacker exploiting your website can do that too.

In other words, when there are cyber attacks that hijack devices, websites, and home computers to use as weapons in cyberwarfare, updating websites this way is dangerous, reckless, and irresponsible.

Unfortunately, Drupal has built a similar mechanism for auto-updating contributed modules on a site, just as easily.

Fortunately, both WordPress and Drupal can be hardened so you can't update a site through itself, making it much, much harder for an attacker to break in and use your site as a weapon. (Not to mention what they can get from your site directly...)

It's harder to do in WordPress, but it can be done -- and we've done it with our WordPress Maintenance plan. We apply all updates on dev copies, we've automated the necessary search and replace so we can test changes effectively BEFORE they are put in production, and we've hardened the hosting environment to make it so an attacker can't put a file somewhere they can execute it. When we manage the environment, WordPress (or Drupal) cannot modify itself -- this hardening alone has entirely eliminated the risk of many of the recent dangerous vulnerabilities we've seen. And we can also sandbox each site in an isolated container so it can't even see or reach other sites on the same server.

The tools and techniques for keeping Drupal sites and WordPress sites secure and up-to-date are surprisingly similar. However, once again, it's the usual practice that is entirely different. And part of this is because it's much harder to run copies of a WordPress site than a Drupal site.

How do you make a living, as a developer?

Both Drupal and WordPress have a radical underbelly: The GPLv2 license. For a while, this was the most widely used Free, Open Source license, the very definition of copyleft, and it's still a broadly used standard.

A key tenet of the GPL is that you cannot restrict what people do with your code after you've given it to them. Anything that builds on (is "derived from") GPL code can only be used with the GPL -- which means if you try to restrict how other people distribute and use a module you create derived from Drupal or WordPress bases, you lose the right to use that code in the first place!

So what does that mean?

Apparently to many WordPress developers, it means you can't easily sue anybody who copies your commercial plugins -- but it seems to be widely acceptable to make commercial plugins and themes, and charge a license fee. I'm not sure how many commercial WordPress plugin creators there are, or how successful, but it's a huge market and it seems like the community largely supports these commercial plugins.

Which has led to the great fragmentation of the WordPress Plugin ecosystem. This is a large part of why it's such a mess -- commercial plugins are generally developed by a single company, they perhaps get fringe contributions from users, but largely the number of contributors to a commercial plugin is small. And plenty of competing plugins get developed, each with their own business model, and what plugin works with what other one is largely a question of how the various plugin writers form alliances, and what customers demand. This leads to... a huge mess. And it means there may be little consistency across sites that solve the same things.

On some WordPress blogs, I saw posts flaming a plugin developer for "stealing the code" from another plugin, and "harming the developer's ability to make a living" by developing a free, competing plugin. Well, that's exactly what the GPL explicitly makes not only possible, but desireable.

In the Drupal world, on the other hand, it would be the commercial plugin writer getting flamed for not working with the community to make a plugin that solves everybody's needs. There's pretty strong community pressure to make your plugins and modules open and free, so that many more developers can contribute the functionality they need.

This leads to Drupal modules becoming "best of breed" and generally ending up far more widely used, cover far more user scenarios really well, and far better quality. The number of contributed plugins you need for a sophisticated site has dropped substantially with each major new Drupal release, as more and more "power" modules like Views, Rules, Groups, Membership Entity, Message, Panels, and Commerce have emerged that are capable of replacing hundreds of individual single-purpose modules.

So if you're an ambitious WordPress shop, you aim to make a subscription plugin that thousands of sites will buy and give you an ongoing stream of income.

Whereas if you're an ambitious Drupal shop, that's not so much of a viable avenue -- but you can become a much bigger player by owning and leading the development of what becomes a critical module. Aside from Acquia, there are dozens of highly respected, multi-million dollar shops that are known leaders in Commerce, Organic Groups, Booking systems, Learning Management Systems, CRM, and more.

While both WordPress and Drupal are, technically, open source software, the Drupal ecosystem is a shining example of how successful that strategy can be. The WordPress ecosystem, on the other hand, seems to act more like the previous software generation's Shareware world of lots of tiny software companies selling one-off solutions of dubious quality. And many seem ignorant of the GPL, or apologetic about it...

Where does that leave us?

It's true that WordPress has an order of magnitude more sites deployed than Drupal. But the further up the value chain you go, the more you find Drupal. Drupal runs many top Internet sites -- and while WordPress appears in that rarified air, it needs to be heavily modified to handle the needs -- and at that point becomes pretty much custom software.

Compared to WordPress, Drupal:

• Costs less to maintain (our Drupal maintenance plan is $100 less than WordPress, because we can automate quite a bit more, while WP involves many manual steps that cannot be easily automated).
• Has far better tools to manage content
• Can be easily re-skinned for a new look, usually with no change in functionality or architecture -- allowing us to change even old sites to a mobile responsive design with less effort
• Can easily grow with your needs over time, plugging in new functionality that generally tends to work with the entire ecosystem, rather than taking you off to spaghetti-land
• Has just finished modernizing their code and doing the hard work that will make future upgrades pretty much painless, while WordPress is rife with old code that may be in need of a big rewrite in the next year or two
• Is a content management powerhouse that competes with, and effectively beats, the highest end commercial CMSs
• Has drag-and-drop page layout managers that compare well to Software-as-a-Service platforms like SquareSpace, Wix, Weebly
• Has a powerful migration utility in core, which can be leveraged for integration with back office systems
• Tends to cost less if you're developing a complex site -- lots of users with lots of different user stories -- e-commerce, event registration, user-generated content, CRM, information database, course catalog, etc

Compared to Drupal, WordPress:

• Is easier for most designers to theme
• Has many more developers
• Has many more canned themes available
• Is easier to get going out of the box with little knowledge
• Tends to cost less if you're developing a really simple site -- brochure site, blog

So why are you now working with WordPress?

As it turns out, it's not that hard to work on WordPress. After all, that's why it's so popular. The language is the same. It runs on the same technology stack, can be managed by most of the same tools. And most of the functionality is surface-level, easy to find, easy to debug.

For our customers who care about their website remaining up, protected, and regularly tested, we can apply the same process and automation to WordPress that we can with Drupal. There are still more things we need to do manually, but we can test all our changes safely away from production, do visual regression testing on all code changes, and provide a safe and secure hosting environment that we can easily recover if something happens.

What we're already finding is that we need to turn to code to fix a huge number of things that are simple to do in Drupal.

In Drupal, much of our support is providing help around how to accomplish a certain task -- a huge number of requests are things our customers can do themselves without HTML or coding knowledge. We're already finding that a lot more WordPress requests involve changing page templates or writing code.

You'll hear about the infamous steep learning curve of Drupal. It's true, there is so much power there that is hard to learn, hard to even know it exists -- but if you learn the tool, you see how powerful it is and how easy it is to accomplish things that are very difficult in WordPress.

And so our thinking is, there's got to be a ton of WordPress sites that would be far easier to grow and enhance in Drupal. We're happy to have the steady paycheck of doing lots of one-off patches on WordPress sites, but for those customers who would rather be able to do it themselves, we can provide an easy migration path into Drupal where they have that power!

For that matter, go ahead and build your site in WordPress. When you're ready to start actually making it a valuable asset for your business, we can port the design into Drupal, suck over all your content, and build out the database you need to make your business more effective!