Wordpress or Drupal? We get asked this question a lot - and with good reason. Investing in a new web presence is a big effort, and the investors want to make sure they're making the best decision. While every case is unique, we wrote the following comparative article to help take the first step in choosing the right platform.

Regarding the general learning curve for new WordPress vs. Drupal users, WordPress features rather simple side navigation, and content administration focuses primarily around visual builders (WYSIWYG/Gutenberg). On the other hand, Drupal has a little bit deeper navigation on the admin side because there's more to do and more to configure. This can make the admin experience vary from site to site and possibly require more training than WordPress. The content administration in Drupal certainly can, and typically does, include WYSIWYG fields but also heavily relies on custom fields of a variety of types. However, in the hands of talented developers and strategists, this complexity can be well mitigated and can even make content management easier overall.

While it's not a slam-dunk, it's generally easier for first-time users to get around in WordPress vs Drupal.

Both platforms have many user forums, help articles, tutorials, etc, but it's hard to beat the quantity that the WordPress community offers. That said, WordPress, on average, targets less technical users, therefore the community trends away from the developer experience and towards support around black-box plugins. There also tends to be more developers available in the WordPress community, however, given the ease-of-entry to the platform you give up some quality/technical proficiency overall for availability.

It has a larger, but arguably less technical, community.

The ability to translate (ex: languages like English, Spanish, Chinese, etc) and localize (ex: currencies, date/time format, etc) may or may not be an important feature of a site. If it is, it's hard to argue against the fact that Drupal has i18n/l10n baked into its core, while WordPress requires 3rd party extensions for this. That's not to say that WordPress can't perform these duties, but it's an afterthought and therefore not as well-optimized for this as Drupal.

WordPress comes out-of-the-box with 5 basic user roles for managing content. It can be enhanced with plugins but there is no built-in infrastructure for this; it must be created from the ground up by the plugin developers. 

Drupal comes with a pre-built system for creating roles and assigning very granular permission-sets to those roles. It also provides a hook structure for modules to easily add permissions configurations.

While neither platform is inherently more or less secure than the other there are some factors at play here. The first factor being the sweeping market share that WordPress has. In terms of security, the quantity of WordPress sites out in the wild is a liability as it makes it a prime target for hackers. It's typically easy to detect if a site is using WordPress. Combine that with many of the default configurations of WordPress and you have a relatively large attack surface for hackers. Also, with the plethora of 3rd-party plugins and themes, many of them with little to no testing or security audits, there are many opportunities to open up security holes. There are plugins, configurations and other best practices that can help to mitigate these vulnerabilities, but many sites simply don't do this and even sites that do can still easily fall victim to an insecure plugin or theme. It’s also worth mentioning that limiting 3rd-party plugins and themes in favor of custom ones can go a long way in avoiding vulnerabilities.

Drupal has a stronger emphasis on security. Modules also typically come with unit tests (to prevent bugs from cropping up as they're updated) and core/security updates are timely and usually relatively easy to apply. Much of the default configuration is already more secure than WordPress. 

Both platforms have a battery of plugins/modules at their disposal for better security practices, like the ability to enforce password policies or block repeated failed login attempts.

Drupal sites tend to be more secure than WordPress sites, but with capable hands, both platforms can be secure.

WordPress generally dumps all of its content into a few database tables which can work great for relatively small quantities of content but can start to hit serious performance bottlenecks when you start to talk about hundreds of pages. 

Drupal segments their data structure across many tables, which allows for better indexing and ultimately better performance. Drupal also has built-in caching that gives it a serious performance boost in production environments.

WordPress is known for its backward compatibility. With each new version of WordPress that gets rolled out, they rarely remove any functionality and simply add new functionality on top. The benefit of this is that you can be relatively sure that updating WordPress will not break your site. The drawback is that the platform incurs more bloat and performance suffers because of it.

Drupal has had a bit of a checkered past regarding upgrades. Somewhat recently, going from Drupal 7 to 8 was a complete rewrite. While the admin side of the CMS might look very similar from 7 to 8, the engine has been completely rebuilt on Symfony. This has given Drupal developers some really great new tools to use to build very powerful sites very quickly, but we've also lost many modules that were written for D7 and never ported to D8. The Drupal roadmap assures us that future upgrades from D8 -> D9 and beyond will be much smoother.

But both platforms are here to stay.

One aspect that's often brought up when comparing Drupal and WordPress is how easy it is to extend the platform and how many plugins/modules there are available to do just that. WordPress claims over 55k plugins available, while Drupal 8 has only around 7.5k modules. At a glance, it looks like a clear win for WordPress, and the verdict is a resounding...maybe: the reality is more subtle than that. One thing that's often overlooked is that with the rebuild of D8 onto Symfony it is orchestrated using composer, the de facto PHP code package/library manager. This means that in addition to the 7.5k modules you also get access to the 1.8M+ composer packages.

WordPress approaches extensibility with plugins that are generally larger and full-featured and oftentimes do more than just 1 or 2 things. These plugins are usually targeted at non-technical administrators as a way to add or modify features of WordPress with little to no coding. When building a WordPress site it's very possible to accomplish most or all of your goals without having to write a single line of code.

Drupal uses modules as their means to extend the platform. WordPress plugins and Drupal modules are often conflated, and while it's true that Drupal modules can include many features in one module, more often than not modules are meant to be smaller, more single-purpose chunks of code. Even Drupal core itself is comprised of many small modules that can be activated/deactivated as needed.

If you're looking for a more pre-built solution go with WordPress. If you're more technical and looking for a platform you can extend yourself, go with Drupal.

WordPress is generally centered around a single WYSIWYG field for content entry. This means that all of the content for your page/post lives in one big field, including some/a lot of markup. Even the visual builders are all just writing the markup in the background for you. The advantage of this is that it makes the admin experience relatively consistent from site to site. It also allows for various different visual builders to assist in managing this content: Gutenberg, Elementor, Divi, etc. This can make content management a breeze, even for low-tech administrators. The downside to this is that all of your content is in one big chunk and not necessarily easily parsed out. One practical limitation of this is that if this page/post needs to be displayed in more than one place in more than one form (for example, a full-page layout vs a card layout on an index page) throughout your site you'll most likely need to enter the same content again and again. This can lead to difficulties in keeping content up to date and/or be more of a burden on your administrators. Advanced Custom Fields (ACF) is a plugin that any self-respecting WordPress site is rarely without. It can help fill in the gaps in functionality around semantic content. As critical as ACF is, however, it’s still functionality that’s not part of core and therefore may not be as well optimized as it otherwise could be.

Drupal’s content management strategy focuses on custom fields. Content entered into those fields is semantic and available for displaying in multiple different formats or display modes, which Drupal provides as part of core functionality. Content entered this way can be easily automated or even presented in an API for programmatic access. Drupal content can even be related to other pieces of content through entity reference fields (a native field type). This approach to content management is what makes it so scalable and flexible.

The tradeoffs to WordPress’s single-WYSI nature are performance and flexibility.

Given the availability of templates and plugins, WordPress projects tend to cost less than Drupal, provided those available contributions to accomplish your goals. WordPress’s forte is providing the ability for a CMS admin to add almost any functionality via plugins as well as heavily customize the look of the site theme all through the admin interface. All that tooling can go a long way in speeding up development time and therefore reducing costs. 

Drupal nearly always requires a developer to be involved. Also, given the more flexible nature of content type and field configurations, it’s not as easy to make templates available like themes are available for WordPress. This typically drives up the cost of a Drupal site compared to WordPress.

Unless you’re fighting against the WordPress grain here, you can typically build a WordPress site for less than a Drupal site.

WordPress sites can often be built with existing themes and plugins without the need to write any custom code at all. Drupal typically requires a developer.

WordPress was originally built as a blogging platform and over time, general CMS functionality was added. Drupal can also be configured to be or include a blog but was more general-purpose from the beginning.

Deploying code with either platform is relatively easy. Deploying CMS configuration changes with WordPress is challenging. There are a number of tools that can assist, but it’s still somewhat of a bumpy ride moving changes from one environment (ex: development) to another (ex: production). Drupal 8 comes with a configuration management plugin that can snapshot these CMS changes to a config file on disk that can be easily version controlled and easily deployed to the next environment.

Both solutions have the ability to provide a JSON API. WordPress now includes a pretty robust API by default. It’s fairly comprehensive which means it’s likely to be useful without any additional configuration; this also means it’s pulling a lot of data you may not need so it could easily be used by bots to stress your database. Drupal allows you to build your own APIs via the Views module, which gives you full control over its configuration and what data is and isn’t included.

WordPress and Drupal are both great platforms that can each be the right choice depending on the needs of a particular project. It’s up to each project with their given set of circumstances, requirements and budget to decide what’s best. In general, if you’re building a site and are most concerned with getting something up quickly or you’re on a budget then WordPress is likely your best option. If you’re a developer or need more flexibility or have more complex needs then Drupal is probably going to be the best option for you. What will you choose?