We have nothing against WordPress, we recognize its strengths—and its weaknesses too. We've chosen Drupal. That doesn't stop us from being questioned and challenged about this choice. Here is the latest clarification—thank you, Ludovic :)
It still happens, during consultations or when advising on an architecture, that we’re asked why not use WordPress instead of Drupal. As you know, we appreciate Drupal, with its strengths and weaknesses. We decouple when it doesn’t do the job properly... We choose technologies based on their advantages, but above all according to the team's mastery. Above all, we do not engage in propaganda. WordPress is an excellent tool for those who know it well, for certain projects. We have to admit that we are not structured enough for that type of project.
Popularity
Recent studies show that WordPress powers a quarter of the global web. Drupal’s share is much smaller, but if you focus on business or organizational sites with more than 1,000 employees, Drupal sites then represent 22% of the sector.
Large enterprises and public institutions favor Drupal over WordPress for its robustness and scalability.
We also note that Drupal is the default CMS for the vast majority of French institutions (on gouv.fr).
Target Audiences
WordPress was historically a blogging engine and could be said to have outgrown itself by becoming a very popular solution for small “showcase” sites and even some major organizations.
Conversely, Drupal has always been a generalist solution from its inception, remaining open and not presupposing any particular site type. Drupal is often described as a CMF (Content Management Framework) rather than a CMS (Content Management System). Drupal can power showcase sites, blogs, intranets, e-commerce, forums, enterprise social networks, and more.
This great flexibility can be intimidating at first compared to more targeted solutions, but in the medium term it’s an advantage. Drupal is a CMS on which you can build and invest. Other solutions (WordPress, Joomla) are more immediate but harder to evolve.
It’s true that since version 3.0 of WordPress, its creators have shifted toward making it a more general-purpose product, but it still carries limitations from its blogging roots.
Ecosystem and Security
Drupal and WordPress are 2 open source solutions that can be extended via:
- Plugins (in WordPress terminology);
- Modules for Drupal.
Both platforms offer a large number of extensions, with the advantage in sheer volume going to WordPress.
But, unlike Drupal where paid modules are very rare (and seldom used), many WordPress plugins are paid. Especially if you want a complex, high-performing multilingual site, or to customize your content (add form fields, etc.)—you’ll need to purchase “pro” versions of certain plugins.
Multilingual support and the creation of new content types are built-in features in Drupal.
WordPress is very flexible in its plugin acceptance policy on its official site. This has, in the past, led to some significant security problems (malicious code deliberately inserted into free plugins or themes), or disappointments when a paid plugin is suddenly discontinued because of an external event (like being acquired or going out of business).
In contrast, it’s much more difficult to publish a module on drupal.org. It’s reviewed by the community, and real quality control is performed before it can appear in the official listing—especially in order to obtain the “security advisory coverage” label.
Both CMSs make significant efforts to be secure solutions. We believe that Drupal has a clear advantage when it comes to external modules and due to the extreme responsiveness of its team dedicated to security vulnerabilities.
The flip side for WordPress is that its market share (25%) makes it an easy and attractive target for hackers.
Usability
WordPress is often cited as a model of user-friendliness in the back office, and this is deserved. This simplicity goes hand in hand with the simple functional scope of most sites built with WordPress. A complex WordPress site, unfortunately, won’t avoid a complex back office.
The back office in Drupal, while more intimidating and less user-friendly at first, is fully configurable and can be simplified depending on user roles. It’s reflective of its functional power, with some areas that can’t easily be simplified. Its structure is built for scalability.
Since version 8 of the CMS, major community efforts have been made to improve the back office usability and deliver a smoother user experience.
More information: https://www.drupal.org/about/strategic-initiatives/admin-ui-js
You can also check out our best practices for improving the contribution experience:
Enhancing the Contribution Experience: Comfort in the Drupal Back Office (March 2021) -
Customizing the Drupal 8 Backend — Solutions and Tips (July 2020) -
“Yes, but there’s Gutenberg and its pre-configured cloud paragraphs!!”
True, it’s a very popular and practical initiative for content editors. Making our clients and projects dependent on a library stored in the cloud is something we’ve always advised against. But now there’s an equivalent in the Drupal ecosystem too, and we'll soon discuss the advantages it brings in terms of efficiency and standards, compared to a modular suite like Layout Paragraphs and Paragraphs.
Decoupling / Interfaces
This is an important topic today, and both solutions emphasize being able to function as a content generation API for:
- A mobile app;
- Other services;
- A "headless" site such as a SPA (single page application) or a PWA (progressive web app).
Since version 8, Drupal has positioned itself as an "API first CMS" and all its resources (content, users, comments) can be exposed as JSON or XML REST APIs without any additional development or modules.
Drupal offers an extensible framework for creating all kinds of APIs and easily extending its default behavior. In this respect, it competes much more directly with tools like Contenful CMS, Strapi, GraphCMS or Prismic.
Scalability / Standardization and Industrialization / Maintenance
As already noted, WordPress still suffers (in our view) from its initial focus as a blog engine (though this has changed somewhat in recent versions), and while it offers great ease at startup, its structure makes it difficult to scale.
Since version 8, Drupal is built entirely on one of the two leading PHP frameworks in the industry: Symfony. It also uses other standard solutions to manage dependencies, its template engine, etc.
Finally, there’s a whole ecosystem of contributed modules (Migrate) allowing the migration of content and users from earlier versions.
So…
For all these reasons, we will continue to use Drupal exclusively for our projects. We’ll decouple it with more powerful tools whenever we feel it’s necessary... And we’ll continue to keep an eye on WordPress’s evolution from afar, but with goodwill.
