Tools CMS Features Lead image: Lead Image © Zoya Fedorova, 123RF.com
Lead Image © Zoya Fedorova, 123RF.com
 

WordPress, Joomla, and Drupal compared

Content World

Open source content management systems have an abundance of extensions scattered across the web. We compare the features of three CMSs against various consumer requirements. By Tim Schürmann

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.

The tidy back end in WordPress comes up with a dashboard after logging in that provides important information and statistics. The red-circled numbers on the left remind you to complete updates.
Figure 1: The tidy back end in WordPress comes up with a dashboard after logging in that provides important information and statistics. The red-circled numbers on the left remind you to complete updates.
The Joomla back end gives an overview of the current circumstances after logging in and offers quick access to frequently used functions.
Figure 2: The Joomla back end gives an overview of the current circumstances after logging in and offers quick access to frequently used functions.

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).

On request, Joomla installs one of several sample pages, which are well suited as starting points for your own Internet presence.
Figure 3: On request, Joomla installs one of several sample pages, which are well suited as starting points for your own Internet presence.

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.

After logging in, Drupal displays an appropriate menu on the left that you can access to manage the pages.
Figure 4: After logging in, Drupal displays an appropriate menu on the left that you can access to manage the pages.

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.

The pages generated by WordPress are based on blogs by default.
Figure 5: The pages generated by WordPress are based on blogs by default.

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).

In WordPress, a few mouse clicks in the Customizer are all it takes to adapt the design as you like. The tool now resembles a simple web construction kit.
Figure 6: In WordPress, a few mouse clicks in the Customizer are all it takes to adapt the design as you like. The tool now resembles a simple web construction kit.

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 with modules [27] [28]

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])