
WordPress, Joomla, and Drupal compared
Content World
Statisticians view WordPress [1], with its market share of around 30 percent, as by far the most popular content management system (CMS) in the world [2]. Despite this superiority, it still might not be suitable for your website. Open source competitors such as Joomla [3] and Drupal [4] attract users with interesting and unique selling points.
If you want to set up a website for a new product or a corporate blog, you are often faced with a complex decision. The question is: Which of the three widespread open source CMSs best meets your requirements? In this article, I will look at the features and extensions of WordPress, Joomla, and Drupal to help you determine which might best meet your needs.
Table 1, which you can find at the end of this article, provides a structured overview of an extensive set of features that appear to be worthy of note or simply helpful when setting up a CMS. Among other things, it shows whether a feature is available directly in the CMS core or whether a CMS integrates it as an external component in the form of a plugin, module, or extension.
How a feature is implemented can mean a significant difference in performance; the developers of the core CMS often focus primarily on the core features, whereas third parties handle quality control for external components. If I see major deviations between a function in the three systems, I mention it.
In WordPress, Joomla, and Drupal, the basic features are similar to the methods used by the systems to manage websites: Page operators simply type in their text and then decorate it with images. The majority of the formatting and publication is handled by the corresponding CMS.
Access is controlled by a sophisticated user management system. Additional functions can be retrofitted easily by site operators with the use of extension packages. The appearance is determined by design templates that can be replaced quickly (e.g., before and during the Christmas season).
However, that's the end of what they have in common.
Back Room
In WordPress (Figure 1) and Joomla (Figure 2), page operators usually edit their websites in a separate area, known as the back end. Because of a large range of functions, some parts of Joomla are confusing and many functions are not self-explanatory. Joomla also wants to phone home with telemetric data by default, although the CMS administrator can prevent this with just a few mouse clicks.


Unlike its two competitors, Drupal is consistently designed to work directly on the website. For example, a click on a pencil symbol is all it takes to edit an adjacent element. Site operators simply perform administrative tasks on corresponding subpages.
Pagey
WordPress originally started as a platform for bloggers, which is still obvious in many parts of the CMS. WordPress distinguishes between (blog) posts with up-to-date text and static pages (e.g., the imprint, contact forms, FAQs), whose information usually does not become obsolete. Posts and pages always consist of a heading (the title), some continuous text, and some additional metadata (e.g., the author). Joomla works exclusively with posts, which also comprise a title, body text, and metadata (Figure 3).

In WordPress and Joomla, site operators supplement the content, if desired, with more data fields (e.g., to save the cooking time separately for a recipe). Although WordPress only allows text fields by default, other data (e.g., a date) can be saved explicitly in Joomla.
In WordPress, site operators simply create a new field under the post text with a mouse click. In Joomla, you need to group the data fields thematically to determine which posts query the corresponding additional data.
Drupal takes this one step further: Site operators themselves determine what data and information compose a page (Figure 4). For example, you can tell the CMS that a recipe should consist of a list of ingredients, a description of the preparation, and an indication of the cooking time. Drupal then automatically creates a form for entering the recipe, for which you can influence the appearance – within limits. Similarly, site operators can also determine the appearance of the recipes on the website – all with just a few mouse clicks.

Give Me Names!
In WordPress and Joomla, posts and pages can be sorted thematically into categories and tagged with keywords (tags). If necessary, site operators can nest categories, thus structuring the website at the same time. Drupal relies on freely selectable taxonomies for categorization. Taxonomies comprise several terms, such as the possible ingredients for a recipe, which can also be arranged in a hierarchy.
Text is always entered in a WYSIWYG editor, which in Joomla and Drupal the site operator can adapt to suit their needs. Alternatively, Joomla offers a simple input field or the CodeMirror editor. WordPress, on the other hand, can automatically create new posts from email. However, the CMS operator then needs to grant WordPress access to a mailbox.
WordPress and Drupal allow visitors to comment on content – as long as the site operator allows it. Under WordPress, the Akismet service helps filter out spam, if so desired. Joomla, on the other hand, offers simple banner ad management and, like Drupal, generates contact forms.
All three candidates offer a search function; Joomla even has two: The younger of the two also delivers suggestions à la Google ("Did you mean …?"). However, this requires you to have previously generated a search index. Moreover, the younger search engine has been struggling with teething pains for years.
Darkroom
An upgrade of the extremely rudimentary media management has been on Joomla's agenda for some time. Until then, site operators can only upload and delete files.
In WordPress, site operators can scale, crop, rotate, and mirror uploaded images. For each media file, WordPress creates an attachment page that allows the file to be downloaded and presented in its full splendor once again.
Images can be grouped, as well, with a few mouse clicks to create a gallery and inserted as such into a post. Under Joomla, the admin first needs an extension to set up a gallery. In Drupal, you first need to define a suitable page structure for this task or use a module, which means you can also crop, scale, rotate, convert to another file format, and even convert to a black and white image. The site operator saves the necessary settings as templates (image styles), which Drupal then (semi-)automatically slots over the images in corresponding situations. A module that you explicitly need to enable alternatively creates responsive images, with sizes that adapt to the screen resolutions used by the user.
High-Gloss
The look of each page is determined by design templates that WordPress (Figure 5) and Drupal call themes and Joomla calls templates. The WordPress and Drupal developers each have a theme catalog on their homepage. WordPress users can even access it conveniently from the back end.

WordPress comes with three quite universal design templates in a contemporary look. Each theme can be adjusted, within limits; usually site operators can at least choose a different color scheme. The adjustments are made in a special live preview known as the Customizer, in which WordPress demonstrates the effect of each change directly on the website (Figure 6).

WordPress themes usually divide a website horizontally into three sections: The logo and menus are at the top, the page content follows below, and a footer concludes the design at the bottom. The theme also provides areas in which site operators store menus and widgets that provide additional functions such as a tag cloud.
Dusty
Joomla only comes with two design templates that are slightly long in the tooth. The younger of the two is based on an outdated version of the Bootstrap framework, which at least proves to be responsive. To find new templates, you have to search for them yourself on the Internet. As with WordPress, templates can be adjusted, within limits.
With Joomla, however, you first need to enable and activate a preview explicitly in the basic settings. After configuring settings, Joomla admins can save these as styles and then quickly retrieve them later at the push of a button. In this way, the site operator can switch quickly between a Christmas and a summer version of the template, for example.
In Joomla, the menu items determine what the pages to be accessed look like and what information they present. The concept not only takes some getting used to, it also makes troubleshooting difficult if subpages suddenly turn up with an unwanted design. Fortunately, however, the site operator is allowed to overlay a different template on each subpage. For example, companies usually make the press release area look completely different from the rest of the site.
A Joomla page always shows the actual page content in a larger region, around which you can place modules in further regions specified by the design template. These regions correspond to widgets in WordPress and offer small additional functions, such as listing the five most popular posts. The site operator also determines which module appears on which subpages.
Like Joomla, each design template in Drupal provides multiple regions. The page content appears in a main region, and Drupal places blocks in the other regions, which each provide additional functions, such as a breadcrumb bar.
Unlike Joomla, a block in Drupal provides the page content. The admin decides which blocks appear on which pages. Individual properties of the design template, such as the color scheme, can be customized. At the beginning, Drupal only comes with a simple standard theme with an old-fashioned look, but at least it is mobile-friendly.
Personnel Department
WordPress can protect pages and posts with individual passwords. Only users who know the password can gain access. Alternatively, the site operator can mark a page or a post as private. In this case, only visitors with a WordPress user account are allowed to access the text. Each registered user belongs to one of five predefined user groups (roles). Their membership determines which functions the user is allowed to call. Site operators are not allowed to create their own user groups or change the actions approved for a role.
User management in Joomla, in contrast, leaves virtually nothing to be desired: By using Access Control Lists (ACLs), the site operator defines in detail which user and visitor groups can call which actions and subpages. For example, companies can set up separate private areas on their websites for consumers and business customers. However, the corresponding settings are extremely confusing and are hidden in various places in the back end.
In Drupal, the site operator first defines roles in detail that control access to the functions offered by Drupal and then assigns the appropriate roles to the users. Site operators also can make blocks (e.g., menus) visible to certain users only and thus set up areas for certain users in an alternative way.
In all CMSs, new posts first need to be released by an authorized person. Whereas the site operator in Joomla regulates responsibilities with ACLs, they depend on user groups in WordPress. In Drupal, reviews are only possible with an add-on module that was still experimental when this issue went to press.
Joomla offers a rudimentary internal messaging system and a mass email function. The site operator can use it to send a message to all users. However, this function is not a good substitute for a mailing list.
Find Me!
All three CMSs produce readable URLs, whose structure the site operator can manipulate if necessary. Only Joomla offers further functions for search engine optimization (SEO). For example, the CMS queries suitable metadata as soon as a post is created.
The development of WordPress is progressing at a relatively high pace. As a rule, a new version is released twice a year, which then completely replaces the previous version. After a somewhat chaotic version policy in the past, the Joomla developers have now also adopted this strategy.
WordPress updates are fully automatic if so desired. Joomla only reports the availability of a new version in the back end, which the site operator then has to import with a few mouse clicks. Some manual work is necessary to update Drupal.
WordPress and Drupal can manage multiple independent websites within one installation, which simplifies the maintenance of the respective system; however, setting up this multisite feature is not exactly trivial in either case.
Extensions
Site operators can quickly add new functions with the use of extension packages in WordPress, Joomla, and Drupal. The developers of WordPress and Joomla maintain repositories on their respective homepages that can be accessed directly from the back end. Joomla distinguishes between components that add major functionality, modules, and plugins that handle menial work in the background. Extensions often comprise several components, modules, and plugins, so this strategy leads to additional maintenance overhead.
Because of the popularity of the three CMSs, almost every imaginable occasion and need has an extension. Most of the extensions come from third-party manufacturers, so quality varies greatly. WordPress and Joomla, especially, have numerous outdated extensions on the Internet. In the case of Drupal, many modules have not yet been adapted to version 8 or were still in beta at press time, even though the new Drupal 8.5 version [5] [6] was just released while this article was being written. Site operators still need to take a close look before downloading extensions and should always put them through their paces in a test installation.
Developers can program extensions for all three CMSs in PHP. Joomla relies on a model-view-controller architecture, in which even outputting "Hello World" requires about a dozen files.
Conclusions
Each of the three CMSs has its strengths and weaknesses. WordPress is particularly recommended for blogs, news sites, and websites that frequently publish new text. Thanks to the clear-cut user interface, getting started is particularly painless. In return, site operators have to retrofit many functions with the use of extensions.
Joomla is much more universal and offers a wide range of functions. Sophisticated, finely adjustable user management stands out as one of its strengths, which allows the easy implementation of private member areas. This flexibility also dictates a longer learning curve and a somewhat less agile work process. The confusing online documentation also makes training difficult.
In Drupal, site operators decide which content the CMS should store and present and exactly how this will happen. Therefore, authors do not have to somehow squash a recipe (for example) into the format of a post or look for an extension that implements a recipe collection. Drupal is therefore worth a closer look, in particular if the planned content does not consist (only) of simple posts. However, even with Drupal, users cannot avoid long training periods, although the good online documentation helps.
If the items in Table 1 do not address a feature of interest for your website, that does not mean the respective CMSs cannot accommodate it. The number of modules, plugins, and extensions is huge. The function may already be waiting somewhere for you to find it.
If this is not the case, other open source CMS alternatives might offer exactly the capability you are looking for, including TYPO3 [7], the Magento [8] shop system, Contao [9], or the Django [10] framework, to name just a few.
Tabelle 1: CMS Features at a Glance
WordPress |
Joomla |
Drupal |
|
---|---|---|---|
Version Reviewed |
4.9.4 |
3.8.5 |
8.4.5 |
License |
GPLv2 |
GPLv2 |
GPLv2 |
System Requirements |
|||
PHP version |
7.2+ |
5.3.10, 5.6, or 7.0+ |
5.5.9+ |
Databases |
MySQL 5.6+, MariaDB 10.0+ |
MySQL 5.1+, PostgreSQL 8.3.18+, SQL Server 10.50.1600.1+ |
MySQL 5.5.3+, MariaDB 5.5.20+, Percona 5.5.8+, PostgreSQL 9.1.2+, SQLite 3.4.2+ |
Web Server |
Apache and Nginx recommended |
Apache 2.0+, Nginx 1.0+, IIS 7 |
Apache 2.0+, Nginx 1.1+, Hiawatha, IIS 5+ |
Support |
|||
Graphical Installation Wizard |
Yes |
Yes |
Yes |
User Support |
Forum |
Forum, Mailing list |
Forum, Slack, IRC, Stack Exchange |
Online Documentation |
Yes |
Yes |
Yes |
Back End |
|||
Management via Back End/Front End |
Yes/Partly |
Yes/Partly |
No/Yes |
Multilingual Back End |
Yes |
Yes |
Yes (via the front end) |
Back End Suitable for Mobile Use |
Yes |
Yes |
Yes (via the front end) |
Content |
|||
Saved Information |
Pages and posts (extensions can retrofit further content types) |
Posts (extensions can retrofit further content types) |
Any (page operators themselves specify content types and thus the structure of the pages) |
WYSIWYG Editor |
Yes (TinyMCE) |
Yes (TinyMCE, CodeMirror) |
Yes (CKEditor) |
Preview |
Yes |
Yes |
Yes |
Drafts |
Yes |
Yes |
Yes |
Unpublished Content (hide from all visitors) |
Yes |
Yes |
Yes |
Time-Controlled Publishing |
Yes |
Yes |
Yes (with modules such as Scheduler [11]) |
Version Management |
Yes |
Yes |
Yes |
Content Editable in the Front End |
No |
Yes |
Yes |
Multilingual Websites |
No |
Yes |
Yes |
Media Management |
Yes |
Yes |
Yes |
Image Processing Functions |
Yes (restricted) |
No (retrofit via extensions like Media Kits [12]) |
Yes (restricted) |
Additional Built-in Functions |
|||
Search Function |
Yes |
Yes |
Yes |
Picture Gallery |
Yes |
No (retrofit with extensions like Phoca Gallery [13]) |
No (retrofit with own content type or a module like Juicebox [14], which was beta at the time of writing) |
Comment Function |
Yes |
No (can be retrofit with extensions like JComments [15] or CComment Pro [16]) |
Yes |
Contact Forms |
With plugins (e.g., Contact Form 7 [17]) |
Yes |
Yes |
Advertising Banners |
No (retrofit with plugins like AdRotate Banner Manager [18]) |
Yes |
No (retrofit with modules like Ads System [19] and Advertising Entity [20], both still beta at press time) |
Show/Create Newsfeeds |
Yes/Yes |
Yes/Yes |
Yes/Yes |
Search Engine Optimization |
Partial (with extensions like Yoast SEO [21]) |
Yes |
Partial (further functions can be retrofitted with modules, like Real-time SEO for Drupal [22] or Drupal SEO Checklist [23]) |
Multisite Function (management of several independent websites with one installation) |
Yes |
No (retrofit with extensions like Multi Sites [24]) |
Yes |
Caching |
With Plugins (e.g., WP Super Cache [25] or WP Fastest Cache [26]) |
Yes |
Yes |
Calendar |
Implemented as a module [29] |
Implemented with modules [30] |
|
Design Templates |
|||
Theme/Template Engine |
Yes |
Yes |
Yes |
Template Language |
PHP |
PHP and XML |
PHP |
Design Template Properties Modifiable |
Yes (in live preview) |
Yes |
Yes |
Live Preview |
Yes |
No |
Yes (with fictitious sample page) |
User Management |
|||
Groups |
Yes (default; user management extendable with numerous plugins, such as Simple Access Control [31], Restrict User Access [32], Profile Builder [33] or User Access Manager [34]) |
Yes |
Yes (via roles) |
Access Restrictions |
Access depends on user group |
Access Control Lists (via user groups) |
Access Control Lists (via roles) |
Member Areas (individual pages are only visible for certain user groups) |
Major limitations (password protection or visibility only for all registered persons) |
Yes (via Access Control Lists) |
Partial (only for individual blocks, such as a menu, and with modules such as Private [35] or Nodeaccess [36], which was still in beta at press time) |
Force Review (release of newly written text by a moderator) |
Yes (depending on user group) |
Yes |
Yes (corresponding module still tagged as experimental) |
Two-factor authentication |
With plugins (like Two Factor Authentication [37], Google Authenticator [38], or Two-Factor [39]) |
Yes (Yubikey, Google Authenticator) |
No (retrofit with the Two-factor Authentication (TFA) module [40], which was still in alpha at press time) |
Registration by External Services |
No (only with plugins like Social Login [41]) |
Yes (Gmail account, LDAP) |
No (retrofit with corresponding Social Auth module [42]) |
Internal Messaging System |
No |
Yes |
No (retrofit with modules like a suitably configured Message Stack [43] or Privatemsg [44], which was ported to Drupal 8 at press time) |
Extensions |
|||
Extensions |
Yes |
Yes |
Yes |
Control with API |
RESTful |
No (retrofit with extensions, such as cAPI Core REST API [45] or Rest API for Joomla [46]) |
RESTful |
Maintenance |
|||
Automatic Update |
Yes |
Semiautomatic |
No |
Backup of Website |
Data import and export only |
No (retrofit with extensions like Akeeba Backup [47]) |
No (help with corresponding modules like All In One Backup [48]) |