Drupal

Rethinking and lateral thinking

Drupal’s operating concept is different than many other CMS’s. Drupal does not have strictly divided front- and back-ends. It has instead a highly granular access system that makes links and menus available to anonymous or authenticated users based on assigned user roles and permissions. Administrators configure the system and make permissions available based on the purpose and workflow of the site, not the other way around. Administrative and editorial pages can be viewed in an administrative design (“theme” in Drupal), or these pages can be set to appear in the same theme as the public front-end of the site with a simple click.

To change a piece of content, an editor will find an "edit" button that either allows "quick edit" text elements right in place or open an edit form which makes all necessary functionality available (edit, restore previous version, etc), thanks to the permissions assigned to the editorial user role.

Drupal’s fundamental content strategy is reusability. Those who are used to strict, hierarchical organisation of site content will need to rethink things when using Drupal. Adding a press release usually means you won't have to bother about digging for the right place in a tree structure. It will appear in the press releases list that has previously been configured with a few clicks and has been placed on the press landing page.

Nonetheless, any piece of content can also have its own menu item, but it will only be created when the content itself is created. For those of you who can’t live without your menu tree, you can actually have that, too, since … There’s a module for that!

Freedom and flexibility

Drupal assumes that any content can appear in more than one place. Content creation forms always let you define a summary text, which is then used as a teaser on overview pages. Out-of-the-box Drupal can create chronological or keyword based content compilations. Additional modules allow you to specify compilations based on any conceivable criteria.

One of Drupal’s core functionalities is taxonomy (tagging). Taxonomy terms within (flat or hierarchical) vocabularies can be associated with specific content or whole types of content, making it possible to create and filter compilations of content (or users) with even more flexibility. Content types themselves can be constructed to be whatever you need by simply selecting more fields for the content creation form.

For example: A content type, “publication”, is created with the fields: title, sub-header, author, date of publication, summary, and type of publication. The author field is not a free text field, but a reference to another content type, “author”, which itself is made up of other information, including a photo and biography. To find a particular publication, you can click through the various overviews: all publications from 2010, all posts by John Smith, recent publications of the type “magazine article”, and so on. Overviews and compilations can also be created using hidden fields.

To do all this, you use Views one of Drupal’s most popular core modules. It is a user interface for “click-creating” database queries, like the one we just described. Additional modules make it possible to do an incredible range of things like including slideshows or find and display related content. Using the example above: For showing an author biography contained within a specific publication.

The possibilities for automation and content curation with this technology are immense. You can, for example, create an “archive” list for content older than a specified time that requires no additional editorial input beyond publishing the content itself, since the system knows when something was published. It is even possible to create dynamic filter functions that let site visitors themselves sort through and compile content compilations based on their own criteria.

Hello world!

One of Drupal’s strengths is its international popularity. Drupalists from around the world take advantage of a central translation platform that makes it possible – and easy – to expand and improve Drupal’s user interface. Some 65 well-maintained languages are available and the Drupal project likes to point out that it recognises 228 countries, more than even the United Nations do.

Since there is no division between front- and back-end in Drupal, every language provides a translated administrative and editorial interface. Multilingual websites even allow content authors and translators to work in multiple, different interface languages, according to their needs. Anyone using Drupal is invited to contribute/enhance translations via the central localization platform. The current state can be re-integrated into the own installation immediately.

Use Cases and Dissemination

Drupal is rarely used to just deliver static websites, though it is capable of doing just that, too. It is typical for Drupal implementations to be demanding, highly dynamic platforms, often (but not necessarily) with a high degree of user-generated content. Drupal is popular for government and administrative websites directed at citizen participation, media concerns, NGOs, and Universities.

This strength is shown in the implementation of the Drupal project’s own infrastructure: Unlike some other projects, Drupal.org does not rely on external forums or ticketing systems; it is entirely built on Drupal itself.

A special community

When getting to know Drupal, you will meet its exceptionally open and welcoming community. Alongside multiple international conferences (currently two annual DrupalCons on two continents), there are hundreds of regional and national “Camps” (smaller, more focused conferences), contribution events (like the Drupal Global Contribution Day), and countless user group meetings around the world every year.

It is remarkable that the European community organized an in-place european Drupal conference almost complete based on volunteer work when the DrupalCon Europe 2018 was canceled by the Drupal Association (due to a re-organization of the format).

The recognition that mutual help and support are the best way to advance open source projects has also created a culture of numerous screencasts, podcasts and tutorials. Drupal specialists of many professions are happy to help on all major discussion forums and social media platforms.

Technology

Thanks to its database abstraction layer, Drupal can work with most standard databases, including MariaDB/MySQL, PostgreSQL, and SQLite. Plug-in modules allow connections with MS-SQL and Oracle databases. For search functionality beyond that offered in Drupal core—including faceted and federated search—server-side Apache Solr or Elastic Search are often used on Drupal sites plus some of the promising younger search engines like Meilisearch. There’s a module for each, too, of course!

From version 8 on (released in November 2015) Drupal includes significant portions of the Symfony 2 framework. This has facilitated configuration management for continuous integration by large.

The Symfony depedency has shortened the usual "lifetime" of a current major release. While the major releases 6 and 7 have been supported for around eight to eleven years, "end of lifetime" (EOL) are much reduced from 2020 on. Therefore updating to major versions has become way less effortful. The major release updates to version 9 and 10 integrated seamlessly. If long-term support (LTS) is critical for the decision, Drupal definitely has a strong point here.

New in Drupal 11

The current version introduced the following as stable features:

• Workspaces for complex content staging, e. g. several changes in the course of a marketing campaign
• Single-directory components (SDC) for building consistent, reusable frontend components including all required code, templates, CSS, Javascript and automated tests
• several enhancements for decoupled setups

Already available as experimental features (that normally become stable after 6 months):

• Automatic updates
• Project browser like known from other established CMS: search for modules and install them directly in the backend

However, it is still a good idea to not experiment on your live website. If you would like to try out new features and learn (trial and error) how to use them it is always wise to use a copy of your website on a staging environment, no matter which CMS you are using.