Last week we talked about using the right tool for the right job, the differences (and overlaps) between Drupal and WordPress, and the costs of choosing the wrong content management system. We’ll pick up with how to choose the right content management system (CMS) for your organization.
Take stock of your organization and its needs
It may help to answer the following questions.
- How big is your organization? How many users will your website have, and how technically experienced are they?
- What kind of services will your website integrate with? What needs do those services serve in your business, and how committed are you to them?
- What kind of security or information integrity constraints does your business have?
- What kind of information are users looking for from your website? Is it mostly text? Storytelling with images and videos? Rich, interwoven data that your users want to search and filter?
- Do you have existing data that you need to migrate to the site, and what format is it in?
Now, consider the advantages and drawbacks of each platform.
There are exceptions to every rule, and almost every potential problem in this list can be circumvented by a third-party tool, a clever developer, or a patient-user. However, it’s useful to get to know the platforms and their character “out of the box.” [The following thoughts are anecdotal or opinion-based, and not the result of a scientific comparison. Your mileage may vary.]
Feature set: WordPress and its plugins tend to give you features straight out of the gate, whereas the Drupal philosophy is more about giving you a suite of tools to create the features you need.
Layouts & content editing: While Drupal 8 has made significant strides in this area, WordPress is generally more user-friendly for beginners, and users tend to report a steeper learning curve with managing Drupal content. Thanks to its considerable market share, common “storytelling” type content with what-you-see-is-what-you-get editors feel more native with WordPress.
With the launch of WordPress 5.0 “Gutenberg”, the entire editing experience has been rebuilt for media-rich pages and posts. “With blocks, you can insert, rearrange, and style multimedia content with very little technical knowledge. Instead of using custom code, you can add a block and focus on your content.”5 You can play around with the editor at https://testgutenberg.com/
Data structure: In direct contrast to the above, more complex data structures can start to make Drupal seem like the easier-to-use option. WordPress has a hard time managing thousands of items or content types with many fields and doesn’t provide as many tools for presenting and organizing complex information.
Drupal’s taxonomy system, views module, fields, and content types are more robust and complex than WordPress. WordPress has nothing out of the box to create extra content types and taxonomies. You’ll need to define them in functions.php template file or use plugins such as Advanced Custom Fields or CPT UI.
Drupal’s Views system is a rich interface that allows editors to create custom displays of almost anything on the site. While it can be initially overwhelming, this kind of tool gives Drupal users a huge amount of leverage over complex content.
Ease of Use: If you have limited knowledge of website development, WordPress can be easier to understand. You can set up a simple blog site within minutes with basic WordPress knowledge. WordPress’ interface is much simpler and cleaner to understand quickly.
Drupal is more developer-centered, with a higher learning curve. If you want a more custom-looking and custom-operating website, you’ll need a working knowledge of PHP and a willingness to learn your way around interfaces. Drupal 8 has doubled down on this concept by rebuilding on the Symfony framework. While views, taxonomy, menus, and other components are still built in the UI, any deep customization requires object-oriented programming experience.
Design: It’s obvious that what the end product looks like is one of the most important aspects of choosing a CMS. Both platforms have a number of out-of-the-box theme options and can be highly customizable. WordPress has a number of free themes and a huge paid theme market. The free themes tend to be read-to-go for storytelling content. Drupal’s basic themes are more spartan, probably because the platform doesn’t make assumptions about what kind of content it will be housing. For the same reason, and due to a difference in culture, Drupal doesn’t offer as strong of a paid theme market.
WordPress‘ default 2020 theme looks pretty good out of the box for basic content…
… while Drupal’s default Bartik theme has a definite “some assembly required” vibe.
User base and development philosophy: The WordPress community seems to have a bit of a vicious cycle: it’s more comfortable for the average user, and there’s a huge contributed-code community, so lots of its plugins can be a mess code-wise. WordPress does have development best practices available on the web, but these standards are not required for contributed plugins. Plugin functionality can be great for specific use-cases, but absent or implemented in head-scratching ways for others. If you’re writing your own plugin, there’s likely to be a lot of different ways to solve the same problem and not a lot of guidance on which one will work best.
Drupal’s philosophy is more rigid. Modules will only be considered supported if the code can pass automated tests, and the same is true of patches. This makes the lifecycle slower, and can be frustrating when trying to resolve tickets, but it makes the code more predictable. The Drupal module ecosystem doesn’t really “do” paid modules. Common use cases are generally handled with popular modules that get enough updates through sheer numbers of users. For the big modules this doesn’t really affect release cycle; for small modules, often a paid model could be better because it can incentivize developers to work on the project. Some Drupal modules are sponsored by an agency, or an org will hire an agency to build a module that then becomes available to the community.
In short, WordPress is a bit more “anything goes.” If you’re expecting a freewheeling, “cowboy”-style development process, it’s going to be cheaper to do it in WordPress – but you might accrue a lot of technical debt in the process.
Integrations: Both platforms have a massive number of integrations with other web services. Many organizations manage their newsletters, events, event registrations, payments, etc. using services that are technically separate from their website itself. It’s critical that a CMS work seamlessly with any business-critical services. Customization in this realm can be costly and unpredictable, since use case varies from organization to organization.
Salesforce: Drupal’s Salesforce Suite is thorough and customizable, but requires a good amount of setup overhead to get moving. WordPress has a number of one-offs and lightweight integrations, but no robust competitor to the SF suite.
Commonly, organizations will use a simple integration with Salesforce as the canonical data source – writing content from the CMS to Salesforce, sometimes using a tool like FormAssembly, and reading data back from Salesforce to display on the site. This way the “write” piece can be done using a tool, and the “read” piece is the main customization effort. Either platform can support this workflow.
A higher-overhead setup is to do a complete two-way integration. One system or the other must still be canonical for data purposes, but this level of integration can be necessary for larger, more complex, or higher-cadence businesses. In this case, Drupal has more reliable and extensible tools.
Community: Both have active communities. WordPress has a much bigger usage of the paid plugin model.
Security: Both have active security teams made up of community professionals. These efforts are supported by major players for each platform, Acquia (Drupal) and Automattic (WordPress). Sometimes their security teams even work together on major PHP issues, as in the XML-RPC denial of service vulnerability in 2014.6
Unsurprisingly, WordPress’ standing as the most popular platform also means it’s the most frequently hacked platform (83% of sites cleaned in 2017, and 94% in 2019 according to studies by Sucuri.)7,8
However, WordPress is on the upswing with a significant improvement in having up-to-date software. As of 2019 fewer WordPress sites have outdated core components compared to Drupal and other platforms, indicating that much of WordPress’ threat profile is just due to its footprint on the internet. Similarly, a town with many apartments and fewer houses would likely see more burglaries in apartments than houses.8
Translation and internationalization: Both systems have tools to support internationalization. WordPress’ tools are a bit more basic and start working out-of-the-box. Drupal allows you to custom translate almost every word on the front- and back-end of the site, but require more setup time. (Starting to see a pattern here?)
Migration: WordPress has a REST API create content; because content is usually in a simpler data format, CSV-import style plugins can be effective. Lots of community plugins exist that can do basic migrations, like bringing in Drupal pages and tags; however, these will “flatten” most content.
Drupal has an extremely robust Migrate API that includes all the tools you need; however, the code itself must be written on a project-by-project basis. This workhorse is great for migrating from WordPress, random CMSes, Excel spreadsheets, or even giant directories of text files, but can be daunting to undertake.
There are tools for migrating away from either platform. This is an important aspect to consider when picking a platform. Housing your content on a proprietary platform with no emigration tools can be massively frustrating when it comes time to change systems.
Visualizing your requirements
Remember our Venn diagram? Let’s revisit it.
Based on what you brainstormed about your organization earlier, imagine drawing a circle on the top of this Venn diagram representing where your requirements lie. A circle further to the right, closer to the mauve “Drupal” section, might be better served by Drupal. And a requirements set closer to the blue section might be better served by WordPress.
Choosing a platform really isn’t black and white, though. (Or blue and mauve.) It’s a gradient, and the choice is subjective. Choosing correctly requires patience, insight, and foresight. The most important guiding question is: How do we avoid taking on technical debt?
Overall, both platforms are free (open source), have a wide range of plugins and modules, have large support communities, and are scalable. They both have their own advantages and disadvantages based on what you are looking for. If you need a website to support a blog, small business, or organization, WordPress’ ease of use and interface will serve you better. If you have complex business needs or are looking for a highly customized website, then Drupal is probably the right tool for the job.