Drupal: Why and How We Use It

Drupal, a CMS (Content Management System), is well-known for some and completely foreign to others. It competes with established brands like Wordpress or Joomla. At our company, we have been working with Drupal since its earlier versions (6 and 7), and today we maintain dozens of websites running on version 10.

We choose to use this CMS primarily for cases in which the client requires full control over their content and needs to update their website regularly. Over the years of using Drupal, we have encountered both its strengths and weaknesses. This article aims to summarize what approach we choose when developing a website in Drupal.

Why we chose to use Drupal

Many years ago, we needed to decide which CMS system we wanted to use for our technology stack. At that time, we had numerous options, but our choices narrowed down to two open-source candidates: WordPress and Drupal.

WordPress, while lightweight and widely popular among the public, did not align with our requirements then, and our perspective hasn't changed much since. Despite its popularity, it failed to meet our criteria. We needed a CMS built on well-known PHP framework and one that embraced Object-Oriented Programming (OOP) principles. While WordPress offered an abundance of community-developed plugins, the lack of centralized control posed potential security risks. The worst thing was that most of these plugins were locked behind the paid premium version, even though we considered them as plugins supposed to provide CMS core functionality. We were also uncomfortable with the ideology of automatic updates, when with one click the entire website, and all necessary plugins were updated, migrations took place over the database and one could only hope that the website was still working. We perceived Wordpress primarily as a CMS for blogs and smaller websites, unsuitable for larger projects requiring tailored functionality extensions for clients.

Considering these criteria and others, we decided to use Drupal. Since making that choice, Drupal has continued to evolve, strengthening its architecture, adhering to OOP principles, and expanding its core functionality. We have no regrets about this decision. Drupal, although more robuts (which we view as a positive), is built on the Symfony PHP framework and offers a comprehensive range of features within its core, including caching, multilingual support, user roles, and much more. Like WordPress, Drupal relies on a community of developers to create modules, but the majority of these modules on the official drupal.org website are free, reviewed, and approved, reducing security concerns. While some paid modules do exist, they are often specialized or tailored offerings from larger companies dedicated to Drupal development.

One significant advantage of Drupal is the ability for developers to create various types of entities and blocks, minimizing abstraction levels and streamlining work for both developers and website editors. Developers will also appreciate the object-oriented approach to extending Drupal's core functionality.

Our configuration for projects

Today we run Drupal in Docker containers, most often in combination with the MariaDB database (there are cases where the client requires another relational database server, for example, PostgreSQL). Since we need to start a new project every now and then, we use the Yeoman tool, within which we have a template created to initialize new projects.

For package management we use the well-known Composer, through which we install and update Drupal itself or other dependencies in form of modules, that we use by default. The most common of these modules are as follows:

• Antibot - SPAM prevention
• Admin toolbar - Improved administration bar
• Composer Patches - Editing/fixing errors in modules
• Better exposed filters - Improved filters for Views
• BigPipe Sessionless - Optimization and caching
• Components - A component approach to website development
• Honeypot - Prevention of SPAM
• Metatag - Meta information for pages
• Pathauto – Automatical URL alias generation based on a pattern
• Paragraphs - Entity for better access to work with content
• Sitemap – Generating a sitemap for SEO and search engines
• Token - Creation of use and use of dynamic tokens when editing content
• Webform - Advanced forms for Drupal
• Realtime SEO - SEO components for pages

Themes and vendor libraries

We always create our own themes based on the design. For the base theme, we choose Radix, from which we create our own subtheme. Radix is built upon the Bootstrap CSS library, which enables us to develop frontend components more quickly and easily. These components are created with the help of the Components module mentioned earlier. Radix also comes equipped with Webpack, which serves as a module builder. We reuse and slightly modify it to suit our needs.

Sometimes, of course, projects require a more reactive approach. In such cases, we opt for Drupal in its headless configuration and use the React framework on the frontend, with Drupal serving as the data source and backend.

During website development, we maintain a set of libraries that we use to create certain website's components consistently across different projects. This library bundle includes Bootstrap (which is essential due to our main theme's reliance on it), Swiper for gallery and slider components, and the Select2 library for select fields. If it proves more reasonable, we write our own CSS rules and JS scripts. However, when there is an existing and well-maintained third-party library available, we opt for it.

To ensure code quality for CSS and JS files, we adhere to internal configuration rules for Stylelint and Eslint.

How we build pages today

For a long time, we grappled with the issue of page composition in Drupal, where there was no uniform template, and each page had a unique visual design. Defining block rules, such as specifying on which pages, languages, or entities they should appear, was a daunting task.

However, everything changed with the introduction of the Layout Builder module. This also reshaped our approach to creating visually distinct pages. We structure web designs to ensure that blocks are reusable, and we establish rules to maintain visual coherence regardless of how the blocks are arranged on the pages. Each block has its own set of Twig, CSS, and JS files, ensuring its isolation from other block components. We no longer have to worry that altering one CSS rule might disrupt the visuals of other pages. To achieve these goals, we create a specific content type (page type) that can be assembled from a library of various blocks to meet design requirements. The Custom Blocks, Paragraphs, and Components modules help us a lot in this.

For pages with a more template-like design, such as article details, products, and team members, we employ a standard approach without the Layout builder. In these cases, we create specific Twig templates for different display modes. Once again, modules like Fields, Paragraphs, Taxonomy terms, Views, and others play a pivotal role in our workflow.

How we maintain Drupal's speed

We always strive to keep our site as fast as possible (who wouldn't, right?). To achieve this, we make use of built-in Drupal optimization modules such as Internal Page Cache or BigPipe, including BigPipe Sessionless, which ensures caching of Drupal pages for visitors.

For each page, we load only the necessary CSS styles and JS scripts for libraries, like Bootstrap. Since pages are constructed using the Layout Builder module, which allows for the assembly of different components (blocks, nodes, paragraphs, media, and more), it is not possible to determine in advance which CSS styles and JS scripts will be needed for these components. To address this issue, we automatically create what we call Libraries in the hook. These libraries are created from the files in the component's folder and are attached to the component's Twig template. This ensures that only the necessary component libraries are loaded on the page.

We further optimize this whole process by minimizing and aggregating CSS styles and JS scripts into bundled files, reducing the number of loaded assets.

After uploading images to the web, we compress them using Drupal's built-in compression features. We also create – so-called - Responsive Images that provide visitors with images optimized for their specific device screen resolution, whether it is desktop, tablet, or mobile. Finally, we convert JPEG and PNG images to the WebP format.

Conclusion

To sum it up, we still do not regret our decision for Drupal. We still think it's the right choice for us and for our clients. During the time we have been working with it, we managed to integrate it with various third-party services/frameworks and tweak it into various forms according to specific use cases. We really experienced the good and the bad with it. Even after that time, Drupal continues to move in a direction that is close to us and we are already looking forward to its further improvements.