WordPress and Drupal are two very popular content management systems that are often compared. The common conclusion to most comparisons is that WordPress is good for blogs or small sites and Drupal is better for big or complicated sites. I believe that conclusion is shallow and that a deeper understanding of the differences is helpful for those who need to make decisions “which one should I use” and for those who need a roadmap for navigating the differences.
Both WordPress and Drupal are platforms for website creation and online publishing. Both are used in a number of contexts and for a variety of purposes. Both have large communities of advocates and proponents. For the purposes of this article, we can assume that they are both awesome, however, the real question is, which one is best for your needs? This post will help you better understand the differences by providing factual comparisons and by drawing from my experience and observations.
WordPress and Drupal Goals – aka Mission Statements
|Mission Statements (1)||The WordPress mission is to democratize publishing through Open Source, GPL software.||The Drupal mission is to build the best open source content management framework—one that represents the newest ideas and best practices in community publishing, knowledge management, and software design. We believe in open source, innovation, globalism, and collaboration.|
What is significant in the mission statements is that WordPress wants to make the publishing of content within reach for all. Because of this, there is an emphasis on making the user interface easy to understand. Developers have followed the principle of “decisions, not options.” In other words, when adding new features they try to set the defaults and not add lots of options that might confuse users.
Drupal emphasizes the “best” and the “newest.” This is attractive to hardcore developers and organizations wanting a modern foundation to build on. Also, note that Drupal refers to itself as a “content management framework.” The idea is that Drupal provides the blocks that developers glue together to build a site. Of course, the Drupal community wants it to be easy to use and have popular appeal and the WordPress community is concerned with best practices and appealing to developers. It just seems that they approach the goals from different starting points.
Of course, the Drupal community wants it to be easy to use and have popular appeal and the WordPress community is concerned with best practices and appealing to developers. It just seems that they approach the goals from different starting points.
WordPress and Drupal: Usage and Market Share
Note that the usage numbers in the table below show all versions. Also, there are other community and e-commerce options than those cited, though those subprojects are the main ones.
|Number of Community Sites (4)||BuddyPress more than 200,000 sites||Organic Groups 28,996 sites|
|Number of Online Stores (5)||WooCommerce 2,077,766||Drupal Commerce 6,121|
|Percent of CMS Market Share (2)||59.2%||2.3%|
|Percent of all Websites (2)||28.3%||4.7%|
Usage numbers are important, but that is seldom the only criteria. Some of the reason for number differences is that WordPress has made it a point to keep backward compatibility between versions. That policy means that it is much easier to stay current with the most recent version but makes it harder for the project to update core features.
Drupal, with an emphasis on being the “best” and “newest”, has totally rewritten itself on each major version up to now. A result of that is that site owners have a large task when they want to upgrade. Drupal version 8 adopted parts of the Symphony PHP framework, which is robust and relatively more complex. This has created a barrier to entry for new or less experienced programmers, resulting in fewer contributions. Coding for WordPress, by comparison, is much easier.
Drupal is aware that the practice of rewriting itself at each major version has hurt it, and it will approach new versions differently in the future. With the addition of Symphony, this might be easier, since Symphony provides a solid underlying core framework to build on.
WordPress and Drupal Terminology
|Design and Navigation||Theme||Theme|
|Child Theme (a parent theme can have only 1 child theme)||Sub-Theme (sub-themes can inherit up a chain of sub-themes to the primary theme).|
|Admin Dashboard||Admin Dashboard|
|Additional Content Definitions||Custom Post Types||Content Types|
What we see by mapping the terminology is that on a high level there are a lot of structural similarities (3). I’ve found that understanding these similarities is most useful for developers tasked with structuring functionality than for end-users. The differences for end-users are significant enough that it is not easy to jump from one system to the other.
Creating New Types of Content
Having special content types helps in organizing a site’s pages. For example, a section for listing staff might have fields dedicated to job title, department, and date of hire. A section for events, on the other hand, needs the event date and starting time, place, and directions. Modern content management systems have the ability to create and segment the content.
In addition to the content types that come with the core platform such as pages and posts/articles, it is possible to define more types of content. With Drupal, this is done in “modules” while with WordPress this is done in “plugins” (although sometimes WordPress themes will define a custom post type in the theme’s PHP functions file). On both platforms, it is possible to define content types using a user interface via the administrator’s dashboard. Drupal comes with a user interface built-in for this purpose which helps to standardize the process. WordPress has support for content definitions but does not come with a core user interface for creating them. There are several popular 3rd party plugins for this purpose.
Updates and Security
One can update themes and extensions from within the administration dashboard on both platforms. It is also possible to update the core system within the WordPress administration dashboard, but not in Drupal’s. Updating the Drupal core requires deleting the old core files and replacing them with the new versions and then running the upgrade script. You can do this manually with an FTP client or on the command line using a Drupal command line tool, called Drush. Updates are a security concern because it is imperative to keep the core, themes, and extensions up to date. It is irresponsible to have a website available on the Internet without a commitment to regular maintenance and updates. Sites running on outdated software become a target for hackers. Because you can update everything from within the administration dashboard, WordPress is easier to keep up to date.
Both WordPress and Drupal have security teams that respond to issues discovered by security researchers and users. For the site administrator, Drupal has a security email list that people are encouraged to sign-up for. Usually about once a month you receive emails about security fixes in the core and in 3rd party modules. WordPress does not have a security email list. The regular Drupal security email list may contribute to a less alarmist handling of security findings within the Drupal community. Sometimes there are “fire alarm” headlines on WordPress news sites about a security flaw in a popular theme or plugin as people try to get the word out so users will update their sites. This sometimes leads to a perception that WordPress has a lot of security problems. However, that may not be the case when you consider the number of security patches in relation to the scale of adoption.
WordPress core defaults to automatically update itself for minor version releases, such as security fixes between major versions. It is becoming more common for 3rd party plugins to offer the option to automatically update as well. Otherwise, there are plugins and tools to help notify you and watch your site for available updates. Because WordPress has the mechanism for automatic updates, the WordPress security team has the ability to force the update of core, a theme, or a plugin that it hosts in its repository. However, they have only used this in rare circumstances where a security vulnerability that might affect a large number of sites warranted it.
Drupal has a fine-grained user permission system and comes with the user interface for it. WordPress has several built-in roles and the abilities to assign users to a role, but you need to install or code a plugin for a management interface beyond the basics. There are several plugins that offer the functionality, but it is another thing to add.
Hosted Repositories for Extensions and Themes
Both projects have hosted repositories for extensions (plugins or modules) and themes and both projects have teams that review submissions to make sure they conform to project guidelines and best practices. However, the Drupal.org repository is more closely curated and reviewed. This is a benefit in terms of code quality and security and engenders more orderliness and less sprawl. The downside of being closely curated is that it discourages contributors due to a long waiting period and some contributions that offer similar functionality are not accepted. The end result is higher quality modules, but a far fewer number to choose from. Worried that contributions have slowed down since the release of Drupal 8, the project has relaxed some of the requirements to make it into the repository.
WordPress, however, has many more options to choose from, but the repository reviews are usually just performed on the first version. Consequently, it is important for site owners to carefully choose plugins and only add ones that have a good track record. New users may be unaware of this or may be overwhelmed by the sheer number of choices.
Both systems are open source software and virtually all of the themes and extensions are as well. This means that as long as you follow a few rules, you are free to use the software as you wish, view the source code, copy it, change it, and give it away. So one might wonder where commercial options come into play?
The WordPress core software, its website WordPress.org, and the themes and plugins it hosts are all free. There are many free themes and plugins available from individuals and businesses on the Web. However, I think it is accurate to say that the WordPress ecosystem is heavily commercialized. What are they selling? In one form or another, they are selling services. There are hosting providers catering to WordPress users. There are agencies and freelancers who design and build sites. There are WordPress maintenance companies to take care of them. Sometimes these are separate and others bundle several services together. In the WordPress ecosystem, there are also commercial, or “premium” themes and plugins. You are not paying for the code, that is open source. What you are paying for is access to download and a license for updates and support. Yes, you can often find a copy for download from some other source, but as long as the prices are reasonable, people seem happy to pay to support the continued success of the product, an instance of enlightened self-interest.
The commercial side of things has also made its way into the WordPress.org repositories in the form of “freemium” options, that is functional plugins and themes with more features available in a premium version. The repository guidelines keep things in check, but it can be frustrating for users to figure out what is included for free and what are paid options. In any event, there are a number of multimillion dollar businesses centered around WordPress.
Drupal has hosting providers, agencies, and freelancers that offer services also. There are some premium Drupal themes, but not very many. There are virtually no premium modules. Commercial interests such as are found in the WordPress ecosystem are strongly discouraged. This keeps things simple for end users but is one of the reasons that there are far fewer options available. It has been difficult for Drupal agencies and businesses to branch out.
Comments and Conclusions
So now we have come full circle. We can analyze the common refrain one hears, especially from those familiar solely with Drupal: “WordPress is better for blogging and Drupal is better for big sites.” There is some truth in that, but perhaps not for the reasons people often give.
First, what I’ve found is that Drupal requires an IT staff person, or an ongoing contract for one because updating is relatively difficult. Even somewhat advanced users, who do not have development or system administration experience, may be uncomfortable with the manual or command line options for Drupal core updates. If you don’t have access to a staff person or contractor who can keep Drupal up to date, then go with WordPress. Yes, individuals, entrepreneurs, and small businesses often don’t have dedicated IT staff, so “check” WordPress for smaller sites.
Second, if your site is going to require a lot of custom functionality or connecting to other systems then Drupal may be the best choice. Being built with Symphony components and Drupal’s position as a “content management framework” is an advantage if you are going to be writing the functionality from scratch. This is where I think the common refrain holds true. Many large sites require a significant amount of custom programming and Drupal provides a good starting base. Check.
However, there is a lot of ground between those two poles. There are small and medium niche sites that need a lot of custom programming and there are medium and large sites whose requirements are largely covered by existing functionality, whether in core or extensions. This is where the common refrain is not helpful. How do you choose?
There are three further steps, which you may have already started, that will aid in making a decision:
- Create detailed requirements, user stories, and mockups.
- Investigate other sites in your market or niche to see how they have implemented similar functionality.
- Spend time testing each platform to convince yourself that the functionality you need is doable or not with each platform.
The first point will help you and your team communicate internally and with others. Don’t be afraid to revise your requirements during the planning stage as it is better to do so upfront. Discuss these internally with the people who will be the end users as a reality check.
I’ve found that people are often more than happy to freely share their experiences with technology implementations. It may even be possible to get a walk-through or demo of their system or have members of your team talk with counterparts in another organization. This type of “due diligence” is much more valuable than saying “Harvard uses X.” The truth of that is that “Harvard” is a large organization and actually uses A to Z.
The last step is an absolute must that should not be skipped. Otherwise, you may end up making a decision based on who has the best marketing presentation. Each platform has strengths and weaknesses, whether in core or in the extension offerings, and you will find those by a proof of concept test.
WordPress started out as a blogging platform. Drupal started out as a bulletin board messaging platform. Both have significantly evolved from their modest roots.
Did I miss an important point of comparison? Is so, please let me know in the comments and I’ll add it.
2) From http://w3techs.com/technologies/overview/content_management/all, June 2017.
3) More information available at https://wp-types.com/documentation/technical-guides/guide-drupal-developers-switching-wordpress/.
5) Statistics for websites using E-commerce technologies: https://trends.builtwith.com/shop.