Drupal vs. WordPress

Why Is It So Tricky to Determine Which One Is Right for You?

There’s a lot of information about choosing Drupal vs. WordPress, and most of it comes from a biased source that ultimately wants to promote their preferred platform. Both will sound like compelling platforms, but some sources will push you away from Drupal because they claim it’s complicated and expensive, or they’ll recommend against WordPress because they say it’s insecure or is best suited for small, templated sites.

The reason there’s not actually a clear winner is that for most use cases, comparing Drupal to WordPress is like comparing a Toyota Camry to a Honda Accord: As a bulleted list of features, it’s tough to say one is clearly superior to the other. So your specific circumstances end up mattering a lot.

Below, we’ve compiled a list of comparisons between Drupal and WordPress that will hopefully help you make a decision. We’ve attempted to make this as unbiased as possible to help you make a decision.

Note that both of those are qualified with “out of the box.” In either situation, the platform can have modules/plugins added or custom code written to bolster the featureset. And whichever platform you go with will require custom configuration and custom coding to get it to do exactly what we need it to do for your website. It’s unlikely that the out-of-the-box configuration on either platform is going to fall directly in line with your needs.

Plugins/Easily Extending Functionality

It is true that WordPress makes it easy for content managers to install plugins to add functionality to the site. Drupal’s model assumes that installing modules is reserved for developers, far away from the purview of content managers. Regardless of platform, plugins rarely work exactly as you’d like them to, and they rarely drop into the site seamlessly without the need for some amount of configuration (or even custom coding).

Certainly it’s possible to have success piecing together various plugins, but I personally tend to lean toward Drupal’s philosophy on modules/plugins: I think it is better to leave plugin installation and configuration to developers, at least on sites larger than perhaps 2 dozen pages.  WordPress will generally make it easy to “drop in” new plugins, but we don’t optimize for that approach because it degrades the long-term scalability and upgradeability of the site.

Flexible Templates and Content

Both platforms can be very flexible, and our approach (regardless of platform) is always to build a component-based site that doesn’t lock you into templates. This all has to do with the approach the developer uses to build the site. Both platforms can be made very rigid or very flexible, so make sure you detail with your developer exactly what is manageable and how it’s managed *before* the site build begins.

Cost/Eliminating the Need for a Web Developer

Even though WordPress has an easier plugin interface, it does not mean that WordPress negates the need for a web developer. Making significant changes to the site almost immediately becomes too complex for a content manager. If your site is more than a few dozen pages, I would be extremely skeptical of any long-term plan that suggests that you won’t need a web developer if you want to add features to the site later. Simply installing plugins or modules is likely going to leave you with a lackluster user experience and create quite a bit of headache in upgrading and maintaining the site.

Editorial Workflow/User Roles and Permissions

Drupal wins here out of the box with its now-built-in “Workbench” module, and generally has a more robust permissions and workflow setup. WordPress will require at least one paid plugin to get it to match Drupal’s level of roles and permissions.

Admin Ease of Use

People generally perceive the WordPress administrative interface to be easier to use than Drupal’s. I would argue that in Drupal 8 with the right organization of the back end, they’re extremely similar. But Drupal hasn’t shaken the reputation that it’s “harder to use,” and in my experience, anyone familiar with WordPress will always consider Drupal to be the lesser experience for content administrators. So WordPress kind of gets a win by default here even if the sentiment might be outdated.

Accessibility and ADA Compliance

This is part of the front-end theme that we will be custom building, so it’s not dependent on platform.

Menu and IA Management

Drupal wins here, at least from a technical perspective. Its menuing system is incredibly robust and integrated into the system in a more scalable way than how WordPress treats menus. It makes it easier for us to do extensive customization, permissions, etc.

You will probably only start to feel the benefits of Drupal’s menu system if the complexity of your site means that you’re going to need customized rules for displaying menu items — e.g., if you have subsections in your site that require their own header and navigation.

From a content administrator’s perspective, the interface is fairly similar in each system: You can choose parent pages and move items to different places in the menu as you see fit.

Speed

Ironically, at least in their raw form, both platforms are kind of slow; that tends to happen when you have a highly extensible rather than purpose-built piece of software. However, that’s why we strongly recommend platforms like Pantheon or Acquia. They include extensive caching to take the weight off the CMS, a content delivery network to speed up delivery of images, and they have well-tuned servers to get every bit of performance out of the platform. With all those things in place, either CMS should be extremely fast.

Security

Drupal wins here in terms of total number of exploits — it’s more common for WordPress to have vulnerabilities than Drupal. Part of that is because there are so many plugins coming from so many places, part of it is that WordPress doesn’t have as much of a focus on enterprise sites, and part of it is simply that WordPress has more market share. WP has definitely improved in recent years, but you’ll need to be extremely diligent with WordPress updates throughout the lifecycle of your site.

Cost

We don’t charge more or less for WordPress vs. Drupal because we end up doing roughly the same amount of effort in both platforms. Which specific features require the most attention differs platform to platform (WordPress will require more effort to get the menu up to speed, but Drupal requires a lot of configuration to get its media handling to be where we want it).

Institutional Resistance

Most often when we recommend WordPress, it’s because the client has had a bad experience with Drupal. Maybe the back end of their last Drupal site was poorly implemented, or the upgrade from Drupal 7 to 8 was a costly and frustrating process.

If you go with Drupal despite institutional resistance, a naysayer can easily point to the fact that WordPress a) has a slightly friendlier interface and b) has significantly higher market share. Given those facts, it’s easy for someone to make it look like a decision to use Drupal was made based on preferences, not based on facts or best practices. So you sort of lose institutional buy-in points right out of the gate.

In these cases, even if Drupal has a slight edge for your requirements, using WordPress might help quell internal fears about the platform, and give people something they’re (generally) more familiar with and more comfortable with.