Introduction to the Drupal WCMS

This chapter is an introduction to the Drupal WCMS. It introduces the Drupal community and the principles it values. It also tells you how to locate information about Drupal.

Table of contents

• Introduction
• About Drupal
  • Some statistics
  • Appearance
  • Drupal vs WordPress
  • Drupal 7 vs. Drupal 9 (and beyond)
• Learning Drupal
• Making contact
• Final word

Introduction

Although there exists a large number of excellent development platforms that let you create interactive websites, this ebook is about using the WCMS Drupal as the primary tool for managing content and serving web pages. Drupal itself is a program, written in PHP, which runs on the server, and relies on HTML5, CSS and JavaScript being interpreted by the web browser for presenting content on the web.

Drupal can, in principle, run on a number of platforms. However the most common environment for dunning Drupal includes the Gnu/Linux operating system, the Apache web server, the MySQL (or MariaDB) database server and the PHP scripting language. These four components are often referred to as “LAMP” from their initials.

Gnu/Linux + Apache + MySQL/MariaDB + PHP is always what “LAMP” means when talking about the Drupal staging and production eniviromnent. In other contexts, MongoDB may substitute MySQL or MariaDB, and that Perl or Python may replace PHP as the programming language.

It is possible to use Drupal without LAMP, but in my experience, this often becomes a hassle. I've stopped doing it. In this ebook, only developing and running on LAMP is dicussed.

The examples and practical exercises in this ebook has only been tested in a LAMP environment.

Gnu/Linux is a member of the Unix family of operating systems. If you're not already a Unix user, now is the time to become one! Without some familiarity with Unix, you will not be able to maintain a Drupal site on a Unix or Gnu/Linux server. Unless you already know Unix, you should read through at least the following ebook: Unix notes. It is a basic and beginner friendly introduction to the Unix command line interface (CLI).

About Drupal

Drupal is a free and popular WCMS that are used by thousands of organisations and individuals all over the world to build websites. One of its main attractions is its extensibility and flexibility.

Drupal is created by Dries Buytaert. The continued development of Drupal takes place under the guidance of Drupal Association. It has a very active community of volunteer developers and users. The Drupal community values the following principles:

• Modular and extensible: Provide a slim, powerful core that can be readily extended through custom modules.
• Quality coding: Elevate high-quality, elegant, documented code above rough functionality.
• Standards-based: Support established and emergent standards.
• Low resource demands: Strive for excellent performance by valuing low-profile coding (for example, minimizing database queries) and having minimal, widely-available server-side software requirements.
• Open source: Stay committed to free software development, and build on and support other open source projects.
• Usability: Be easy to use for developers, administrators, designers, and content producers.
• Collaboration: Support open, cooperative information sharing systems and approaches.

Drupal also tries to provide a stable development environment and have in place a testing framework that stops changes that may break existing contrib modules and themes, or changes that alter public facing strings from being committed. For more information about this principle, see: What patches may be backported to a stable release of Drupal core?.

Drupal itself is written in the PHP scripting language and uses a web server to deliver content to users. The web server uses an integrated PHP interpreter to turn the PHP scripts into HTML pages, using CSS for styling. Most of the Drupal website content, and reports are stored in a database. The database work is performed by a database server.

In other words, the Drupal WCMS is based upon the industry standard three tier architecture that clearly separates presention, business logic and data.

Three tier architecture

Presentation tier (web server)

Logic tier (PHP)

Data tier (database server)

In Drupal 7, the site's configuration is also stored in the database. In Drupal 9 and later, the configuration is stored in the file system, in .yml-files.

In addition to its the ready-to-use powerful content management tools in the Drupal core, Drupal provides a framework that lets site builders add functionality to the Drupal core using contributed Drupal extensions (module projects and themes) as well as non-Drupal free software libraries. If even more customisation is required, Drupal lets developers create their own custom modules and themes and integrate those into their Drupal website.

Some statistics

Being free software, Drupal has a huge user community. According to Drupal.org, 48 256 module projects and 3 002 themes (as of February 2022) has been created by community members. I do not have reliable statistics about the number of people engaged in other collaborative software projects, but I believe the number people involved in the Drupal project is one of the largest in the industry.

According to the statistics on the Drupal.org site, there are currently (February 2022) at least 900 000 websites running Drupal. The majority of those (53 %) are running version 7, followed by version 9 (24 %), version 8 (19 %), and older (2 %).

Several websites monitor the popularity of various WCMSes. In February 2022, W3Techs reports that Drupal has a market share of 2.0 %. The top three are WordPress (65 %) Shopify (6.7 %) and Wix (2.9 %). WhatCMS.org reports these numbers: WordPress: 36 %, Joomla!: 5.7 %, Drupal: 2.2 %.

The site BuiltWith has a broader definition of CMS than the two sites cited above. In February 2022 it provides the following statistics for the top 1 million sites: WordPress 37 % (1st place), Drupal 3.5 % (2rd place) and Joomla! 1.8 % (9th place). The same site also provides statistics for various segments. If we look at the figures for the of the 10 000 most visited web sites, Drupal is on third place with a 13 % market share, after WordPress (36 % market share).

Activity on the Drupal.org website is tracked on this page: Drupal.org Metrics.

Appearance

The screen shot below shows a freshly created Drupal 7 site set up with the default Bartik theme and some built-in blocks deployed. When you first set up a Drupal site, it will probably look similar to this before you start adapting it.

Drupal, however, is very adaptable. The screen shot below is taken from the front page of the Titan.uio.no website.

The Titan.uio.no website is based on a responsive theme named Bootstrap (originally developed by Twitter) that has been further adapted by the use of site-specific style-sheets and templates to a create a site-specific look & feel that gives Titan.uio.no a distict layout that is clearly different from an unadapted Drupal website.

Over one million websites world-wide is powered by Drupal. The Drupal.com website and its sub-site Drupal showcases shows some examples of sites being built on Drupal along with case studies of how some of the featured sites were built.

Drupal vs WordPress

WordPress is undeniably the most popular open source WCMS platform. It has an abundance of themes and plugins available. Creating a website to publish content (e.g. a blog- or brochure-type website) with WordPress is a simple affair, and it does this exceedingly well.

However, if you want to create a more ambitious website, with non-standard pages, and bespoke functionality, things get more complicated. You often have to use a combination of widgets, third-party plugins, and some extensive PHP modifications in the templates to get the job done. Many of the more advanced WordPress applications are only available as “packages” that are not free, but requires a down-payment or a subscription. For instance, while Drupal's GUI SQL query generator (Views) is free software (as in free beer, as well as in freedom). The WordPress equivalent, named Toolset, is not.

One difference between the Drupal and WordPress communities is indeed their norms with regard to free software. The Drupal community is very much dedicated to keeping free software free. For instance: The Drupal community would shun anyone who tried to sell free software, or even shows advertising in the public facing part of a contributed Drupal extension. Freeing such software is not considered piracy, but a civic duty.

In the WordPress ecosystem, it is not uncommon to see “packages” offered for sale that consists of a combination of free software that is licensed under the GPL and other components such as fonts, templates and JavaScript licensed under permissive licenses. The value proposition of the merchant is to make it all fit well together to perform a specific task. Such packages can legally be “set free” by anyone by cleaning up the licensing and redistributing it. However, such packages are not, as a rule, set free by WordPress community members who want to keep their good standing.

WordPress does not have built-in caching, making it quite CPU-intensive and complex page builds may perform badly. Drupal has built-in caching for anonymous visitors to the site. Given that enough memory is available to hold the page cache in RAM, it will outperform a WordPress site if both have an equally powerful CPU on the server. This, however, can be mitigated by adding an external cache (e.g. Varnish Cache) to a WordPress site.

Drupal has a security team that provides oversight over the Drupal core and extensions that qualify for security coverage. Extensions that receive security coverage are clearly marked with a green shield on their project page, making it easy to avoid using those that do not. There is a WordPress security team that does a good job of keeping core secure, but there is AFAIK, no organised security oversight over WordPress extensions (plugins).

The WordPress ecosystem automatically labels any plugin that has not been updated for the last two years “abandoned”. This procedure is not very helpful, as there is no way of knowing what its actual maintenance state of the plugin is. It may just be stable (i.e. not requiring updates), or it may be broken with nobody around to fix it. AFAIK, WordPress has no instititions or procedures for dealing with this. As a site builder, you need to stay vigilant about the plugins you use. If your project relies on an abandoned plugin, any core update may break your web site. The Drupal community, in contast, has in place human-curated procedures for Dealing with unsupported (abandoned) projects. These procedures ensures that when it is decided that an extension is “abandoned” by its current team, there exists a process for adding new maintainers and to change owner­ship, to ensure that extensions continue to be maintained, even if they are abandoned by their initial team. Drupal extensions do not have releases pulled unless they really are broken. In practice, experienced WordPress site builders deal with this by limiting their use of free plugins. This restricts them to creating simple sites based upon what functionality is provided by the WordPress core and a few plugins known to be well-maintained. Drupal site builders tend to build more ambitious websites, making use of the many free extensions that are available and curated in the Drupal ecosystem.

In Drupal themes are only used for dressing up the visual display of a website. All functionality are provided by the core and by module projects. In WordPress themes may also provide functionality For example: If you get a real-estate theme for WordPress, it may provide various functions that someone running a real-estate website would want. I.e. swapping a WordPress theme may also remove functionality from the website. It must be said that this mixing of styling and functionlity is pretty rare. It does not occur in all WordPress themes.

Finally. If you are a programmer and want to create your own extensions: WordPress is procedural, while Drupal 8 and later uses Object-Oriented Programming (OOP). While the relative merits of these two programming paradigms are still contested, I very much prefer the OOP paradigm.

For other opinions, see Pantheon.io and BigTuna Interactive.

Drupal 7 vs. Drupal 9 (and beyond)

The first version of Drupal was released in January 2001. Currently (April 2022) two supported versions of the Drupal core are available: Drupal version 7 and Drupal version 9. Drupal 7 was released on January 2011 (EOL November 2023). Drupal 9 was released June 2020 (EOL estimated to be in 2023). The next major release will be Drupal 10 and is planned for December 2022.

Upgrading a website from Drupal 7 to Drupal 9 is a major undertaking (unless the site is very simple). Drupal 7 is procedural. Drupal 9 is based on OOP. This is a major change. Drupal 10 also uses OOP, and an upgrade from Drupal 9 to Drupal 10 is expected to be incremental in nature.

One of the reasons for Drupal 9 being so different from Drupal 7 and previous versions, can be summed up in the slogan: “Get off the island”. This phrase means that so-called “drupalisms” (things specific to Drupal) should be deprecated, and instead, Drupal should adopt industry standard platforms, tools and practices. Hence Drupal version 8 was built on top of the Symfoni framework (based upon the MVC design pattern), and makes use of the twig theme engine, composer to install and manage the core and extensions, and PHPUnit as its testing framework. This deprecates the procedural design pattern of previous versions of Drupal, as well as Simple­Test and drush (for updates – drush is still in use for other tasks). The tools and practices that are used in Drupal 9 are not only used by Drupal, but by a number of other frameworks. This broadens the knowledge base and makes it easier for new developers with previous knowledge about these standards to learn Drupal. It also means that Drupal core maintainers has to maintain less code, as industry standard code is maintained elesewhere.

Drupal 7 is a very mature platform for hobbyists and small businesses, honed through more than a decade of use. It will continue to be supported until at least November 2023, and this date will be re-evaluated annually.

My belief is that Drupal 7 will continue be supported beyond 2023 as long as it has a substantial number of users. Not everybody that uses Drupal today have the resources and the technical skills to upgrade to for Drupal 9 and beyond. Nor do they need access to bleeding edge technology and industry standard tools such as composer and Symfony. Instead they will continue with their present tools and workflow to keep on having lean Drupal 7 websites that will require very little maintenance.

Because Drupal 7 is an island, with little dependency on enterprise tools like composer and Symfony, it is less subject to the forced upgrades that enterprise Drupal is subject to. There are some exceptions, such as the components of the LAMP-stack that Drupal 7 is built on, but I expect upgrades to the LAMP stack (e.g. PHP 8) to be manageable for the Drupal 7 community.

The main reason I believe that Drupal will remain supported beyond 2023, is that it would be foolish of the Drupal community to abandon Drupal 7 as long as it has a valid use case – enterprise Drupal (i.e. Drupal 9 and later) is clearly not for non-enterprise websites. It iwould simply be bad business for Drupal to force those already using, or looking for, a superior solution for this use case to not use Drupal.

However, out of the box, Drupal 9 is better software than Drupal 7. In addition to adopting industry standards, it has integrated a number of essential components (most notably Views and the WYSIWYG editor) in the core. Another improvement is separating configuration from the database.

Use of Drupal 9 is growing, but slowly. As noted, only 24 % of all Drupal sites run Drupal version 9 as of February 2022. The majority of Drupal sites still uses Drupal 7, probably because the high cost of upgrading a legacy website from Drupal 7 to Drupal 9. If you want a set up a new Drupal website in 2022, version 9 is the way to go.

Up to and including Drupal 7, most non-enterprise Drupal users (e.g. bloggers, hobbyists, communities, NGOs, schools, small businesses) did OK without access to the Gnu/Linux CLI and did not need to use composer. Instead they made use of whatever tools provided by the GUI of their hosting provider. I've seen this called a lean Drupal installation. No staging server – everything in production. And often the whole thing was built and managed by a single person in his or her spare time.

With Drupal 9, this type of lean installation that used to be the norm with Drupal 7 and earlier is no longer possible. Drupal 9 seems to be targeted more towards enterprise websites and is a poor match for the type of website that was easily created with Drupal 7. Drupal 9 may simply be overkill when you just want to build a lean website for a business or a NGO.

In his September 2017 keynote Dries stated that:

I believe Drupal is for ambitious digital experiences

and Lullabot strategist Jeff Eaton tweeted tongue in cheek:

If you want to build a small website, I'm not sure it makes sense to use Drupal today. It's good for… ambitious sites.

Another comment on this keynote from Alexei Rayu: Why Drupal 8 is not for Small Websites. He finds that OO Dupal requires a hosting platform that is more expensive to rent and maintain than the cheap hosting used by small websites for Drupal 7.

To manage a Drupal 9 website, you need to adopt certain enterprise work practices, such as splitting your configuration into a staging and production site. On the staging site, you need access to the CLI and you need to use composer to manage dependencies. I've learnt the hard way that this is an absolute requirement. Some Drupal third party extensions to Drupal 9 cannot be installed and managed old school style (i.e. manually, using the Libraries extension for management).

With Drupal 9, you can still host your production Drupal site on bargain basement shared hosting. You then deploy by copying your staging configuration (i.e. you don't need access to the CLI and composer on the production site), but to run a Drupal 9 website, you should stage your production before you deploy it.

For the bloggers, hobbyists, communities, NGOs, schools, small businesses that used to run small a website on Drupal 7 or earlier, and who don't want the added cost and complexity that comes with Drupal 9, they may need to consider alternatives. For example: BackDrop CMS, flat file CMSes such as Grav, or template driven SAAS approaches such as SquareSpace and Wix.

The main reason for having major updates of the Drupal core in the future is to keep the Drupal core in step with the third party techonologies that Drupal builds on. To learn more you may want to read this section on Drupal.org: How Drupal 9 was made and what is included.

Learning Drupal

The illustration below shows how I regard the three main WCMSes when we compare how hard it to solve various tasks:

Doing simple tasks with WordPress is easy. Doing simple tasks with Drupal is harder. At the simple end of the task-scale, Joomla! is somewhere between the two.

However, when we shift to complex tasks, it is often harder to create a solution with WordPress. If there exist well-matched WordPress plugins for all the things you need to do, you may have some luck – but plugins for WordPress don't always work well together and luck may run out when you try to combine plugins. Drupal has a more modular and scaleable architecture than WordPress. This often makes it easier to solve more complex tasks. Again, Joomla! is positioned somewhere between the two others.

How hard is to learn Drupal? The illustration below is a an attempt to depict the Drupal learning curve. (Some of the roles mentioned has already been introduced in a more general context, in the section about the WCMS development team.)

The slope towards becoming a site builder is relatively gentle. A site-builder is someone capable of building rich and comples websites with Drupal, using standard components and the GUI.

The path towards becoming a developer usually involves a steeper learning curve, as indicated by a steeper gradient in the image above. A front-end developer uses HTML, CSS and JavaScript to give the website a distinct look and feel. A back-end developer uses PHP, PDO (SQL-based) and industry standards such as the Symfony framework to program desired functionality for a specific website.

The highest level of mastery in the Drupal community is a contributor. The gateway to contributorship involves signing up for git-access on Drupal.org, and getting a self-authored project through a peer-review process called “Project Application review” (usually abbreviated “PA-review”). Signing up for git-access is a breeze, but the peer-review process is usually a difficult, prolonged and frustrating experience, as indicated by the “bump“ in the learning curve in the beginning of the path towards becoming a contributor.

Making contact

To contact other community member, use the contact form on the person's profile page.

Some people also lists social media that may be used to make contact.

Twitter will not let you send a private DMs to anyone unless they are already following you, but messages will show up in their public stream if you mention them by name. Example:

@Newbie Your Drupal site has been hacked. How should I contact you?

Source: Brent Ozar.

Final word

This has been a brief introducruion to Drupal. You may want to continue reading the chapter named Learn more about Drupal.

---

Last update: 2022-04-02 [gh].