Dear Ditto,

Should I build my site on Drupal or WordPress? Which platform do you recommend?


Advice from:
Peter Sax
Partner & CTO

Drupal and WordPress are the two leaders in the open source market, and Echo&Co architects and develops on both content management systems (CMS).

Drupal and WordPress are both very popular, solid products, but there are important distinctions. WordPress was originally designed as a blogging platform. While there are very rich and interactive feature sets that exist for WordPress today, many of those are pushing the bounds of what the platform was created to do. Drupal, on the other hand, was designed as a robust and extensible enterprise CMS, with broad applications across website, user profile, and e-commerce management.

Drupal is better designed to support complex content and authoring ecosystems, and integrations with systems like Salesforce. In addition, it exceeds WordPress in overall usability, extensibility, security, and maintenance.

Drupal vs. WordPress

Overall Usability

WordPress gained an early reputation for superior ease-of-use in the late 2000s. It has efficient tools for editors and blog managers, including its sidebar widget system which allows editors to create, drag, and drop granular pieces of content into the site’s sidebar. WordPress also created a superior implementation of the ”what you see is what you get” (WYSIWYG) interface that allows users to create rich text elements such as bold, italic, blockquote, hyperlinks, etc. Its utility for simple, straightforward website publishing is proven.

The newest WordPress innovation is Gutenberg, a replacement for a traditional WYSIWYG editor, which provides a Squarespace-like drag and drop experience within a structured CMS. Currently, 68% of the reviews on the project’s page are 1 out of 5 stars. The problem with this replacement is that critical decisions about page structure should not be made on a per-page basis by content editors.

In order to create an experience that is learnable and persuasive, most decisions about the structure must be made at the system level, by a product manager who has expertise in user experience definition and design. This ensures that structural decisions about site templates and content stem from an understanding of performance objectives and are grounded in usability best practices. When templates are created that deviate from these, it can lead to depreciation of the site’s intent, and fragmentation of its experience.

However, it's important to note that well-designed page architecture can allow editors to make structural page decisions on a per-page basis, where greater flexibility is necessary. This happens through the mixing of structured components on a template with more flexible content elements. When it comes to drag-and-drop content management, it's possible that WordPress Gutenberg will become the standard, but it’s not nearly mature enough to outweigh the strengths of structured content via an enterprise CMS.


Extensibility is the relative ease with which new features can be built on a platform. Drupal natively supports the creation of any number of content types, as well as relationships between individual pieces of content. WordPress supports only two content types (Pages and Posts), offering less variety than Drupal in site architecture. Also, WordPress requires customization in order to achieve basic dynamic, relational, or personalized content presentation. In order to build a unique content type in WordPress, you have to use a third-party plugin. The same goes for the ability to relate two content types to each other.

WordPress’ reliance on third-party plugins for such essential, fundamental features compounds its weaknesses regarding maintenance; keeping WordPress’ core and plugin code up to date with their most recent, most secure release versions.

Regardless of maintenance issues, there also are important differences between WordPress’ third-party plugins and Drupal’s contributed modules. In general, with a WordPress plugin, you get a discrete set of functionality. You don’t often get tools you can use to extend that functionality. It’s a more transactional ecosystem, since many plugins aren’t free. In addition, many plugins also require users to purchase licenses with associated monthly or annual costs. With Drupal-contributed modules (which are always free and open source), you get functionality along with tools — either in the CMS interface or in code — you can use to extend that functionality. The principle of extensibility is embedded in the culture of contributed module developers. WordPress is geared more toward selling digestible, concrete features to a non-technical audience. In short, it’s great for a casual blog, but not great for an enterprise-wide website that needs to expand and grow over time.

The structural design of the database powering the platform also has a significant impact on extensibility. The WordPress database stores all of the values of content fields in a single table, in a way that makes it very difficult to select content or data by a certain criterion. For example, if you have a “shirt” content type with a “color” field, the WordPress structure impedes the retrieval of all green shirts. There are workarounds, but they are cumbersome and should not be necessary. The Drupal database is consistent unto itself; it follows best practices for database design, making it easy to retrieve data.  

For organizations that want to introduce a feature set surrounding personalization or user profile-driven content, connecting user information to content using metadata would be critical to the success. Allowing users to set preferences, query or filter content, etc. would be crucial for creating an enhanced experience for users in the future.

Multilingual is another feature set that benefits from Drupal’s much more extensible database design. WordPress Core does not support multilingual, though there are some workarounds, like using Google Translate or creating two multiple versions of the same page in different languages. In Drupal Core, all content field data is marked with its language by default. No data is ever stored without noting the language. This way, the ability to translate individual content field data, taxonomy terms, and interface text is baked in at the most fundamental level. The entire feature set for translating any content, fields, menu links (information architecture), taxonomy terms, and interface text is part of Drupal core, as are a range of options for detecting the user’s language and serving appropriate content. Drupal is better suited to serving multilingual features.

Finally, Drupal offers a range of tools for federating sites in various ways. The Drupal Core migration tools allow sites that coexist on the same server to pass content back and forth with relative ease. The Domain module suite enables multiple domains to be fully federated under a shared database, allowing for a fully federated CMS experience across domains, and a fully federated search, with minimal development overhead.


We encourage everyone to complete independent research into the matter of WordPress vs. Drupal security. Though all software has vulnerabilities, WordPress is routinely hacked and is poorly designed for security. Further, many plugins on WordPress sites require routine updates. Outdated plugins can pose a security risk, and expose your site to vulnerabilities if not maintained regularly. Drupal’s security team has a strong track record for patching security issues quickly, and applying the updates are easier because of Drupal’s advantages with site maintenance, as outlined below.


Both Drupal and WordPress require maintenance: upgrading the core software and plugins/modules to the most recent version. Site managers should make a copy of the site and place it on a staging environment when testing updates prior to making the update to the live site. On both platforms, it is possible during updates to encounter “regression bugs,” or bugs that are caused by the update. Because this is a much more common occurrence on WordPress for both core and plugins, much more quality assurance work to find and fix regression bugs is required. And since more fundamental, critical functionality is provided by third-party plugins on WordPress, the process of keeping a WordPress install secure and up-to-date is much more cumbersome. Many WordPress third-party installations are developed by independent entities and are cost-based. Because there is no guarantee that those entities will continue to support plugins, this can lead to increased cost and effort over time as these plugins need replacing. In contrast, Drupal has an open marketplace of free modules typically supported by a broader developer base, so they have greater extensibility and longevity.

If you have more questions on the comparisons between Drupal vs. WordPress, get in touch!

Ask Ditto your questions by emailing

(Don’t worry, your questions will remain anonymous.)