Blog

In this article, I would like to focus on one CMS called Drupal, comparing it from time to time with the most popular WordPress. I discuss more general topics without going into technical details so that you can form an opinion on whether it's worth taking the plunge. I hope this article will spark your curiosity about Drupal, and who knows, maybe you'll join our community of Drupal enthusiasts and developers.

We have a wide range of CMS solutions on the market. Particularly popular is invariably WordPress, which has dominated the market over the years, as can be seen by analysing the table below.

(source: https://w3techs.com/technologies/history_overview/content_management/all/y)

The market share of this CMS is 43%. It is also worth noting that 33% of the sites surveyed do not have any known content management system. Therefore, if we omit this value from the statistics, WordPress has a share of around 64% among the other methods. This is a lot when considering that the following items have a share of a few percent. Speaking of Drupal, here we mean 1.2 per cent among all running sites and about 1.7 per cent, excluding sites without a content management system. Finally, let's take a look at the data on popularity according to typed CMS phrases in the Google Trends tool for Poland in the year 2022.

(Google trends for the popularity of typed phrases in Poland)

In this situation, you might start to wonder why we consider Drupal at all when we have a clear leader in the industry. Don't let the numbers fool you. Instead, I will try to give you an objective overview of selected aspects of Drupal: both those that speak in its favour and those that might give you pause for thought as to whether it is worth using it.

So far, I have given you an idea of what it looks like in numbers. I would like to present a short list of known companies that use Drupal:

• Tesla
• Nasdaq
• NASA
• Saint-Gobain 
• Bayer
• Pfizer
• Randstad Poland
• Jack Daniels
• Yale University
• Oxford University

You will, of course, find several other lists of the most popular companies' Drupal sites on the internet. The only thing worth noting is that some of them may have already changed CMS, so be on the lookout.

At the beginning of the article, I mentioned the WordPress solution, which is perfect for small applications but also for the big ones like White House, Harvard University, Porsche or CD Project.

So when do customers reach for Drupal? This is particularly the case when:

• They are looking for something stable and secure - especially for the pharmaceutical industry (hence the popularity with the likes of Pfizer and Bayern),
• They want a proven solution that can 'handle' not 10 or 15 websites but hundreds and thousands.
• They believe that the cost of the Adobe Experience Manager or Sitecore solutions is far too high,
• They are looking for an Enterprise solution, the only one in the list above with more than 1% market share.

From the customer's point of view, content management is one of the most essential functionalities. There is nothing to be gained by having a website that runs at lightning speed and has advanced features, while adding content would take a very long time or, worse still, no one knows how to handle it.

So what does the interface look like in Drupal? Let's take a look below.

Is it pretty? Well, not really. I would say it's rather old-school. Nevertheless, you can change the theme of the admin panel, so you can always experiment with it and choose the one that suits the client best. I have presented one such theme below.

(Administrative theme - Gin Admin Theme)

Is this relevant? It depends because we are well aware of the importance of first impressions, and this can make the difference between a customer wanting to use a particular CMS or not. On the other hand, the standard theme is very well thought out and practical. Of course, I agree that it could look a little better, but let's give it a chance.

The tabs are grouped thematically, and their number is quite large compared to WordPress, but for managing the content and structure of the site once it is up and running in daily use, we only need a few of them, including the following:

• Content
• Structure -> Block Layout
• Structure -> Menus
• Structure -> Taxonomy

On the other hand, everything else is helpful when setting up, whether it is a simple website or a complex system. We are able to configure a great deal of functionality without looking for extensions (which is the bane of WordPress). This way, the customer does not have to incur additional costs or waste time testing dozens of different modules. I will use as an example the three default modules we can find in Drupal.

1. Views
   The first of these allows the creation of so-called views. These are simply listings of content, either as whole pages or as blocks, which can be inserted between sections of any sub-page. In these listings, you can configure, among other things, the layout, the visible field or the number of items displayed. You can see the effect later in the article, where I used the views module to create a listing of team members.
    
2. Multilingual
   In fact, this functionality has been split into four smaller modules that allow content to be created in different languages. One of these, among others, is responsible for the ability to translate the user interface, while another is responsible for adding content in another language. Nonetheless, it simply boils down to enabling the relevant module and then adding the language in which your website should additionally be available and start creating content. This is great compared to WordPress, where you have to choose the right add-on from the many available that third parties have created, install it and usually pay a fee for the full version. In Drupal, this is available out of the box, and setup takes about 15 minutes.
    
3. Contact
   The third module is the forms module. It allows you to create any number of them, together with any number of fields. If this functionality is not enough for you, you can download the Webform module. We then have the full range of possibilities at our disposal. It is worth noting that the modules here are free and developed by the community and, most importantly, undergo verification for stability and security. This is shown in the image below:

(Extract of information of the Webform module)

This is only a drop in the ocean of what Drupal already offers once installed. In this article, however, let's focus on the essential parts of the system that are used when building websites. I encourage you to get Drupal installed and review its capabilities. Descriptions of specific modules with examples of their use will appear in future articles. Also, keep following us on a regular basis.

Easy and fast content creation should be an essential feature of any system. Let's take a look at what this looks like in Drupal.

The system allows any type of content to be configured. By default, there are two types available - articles (article) and simple page (basic page). These can be extended to any field. The most significant advantage here, however, is that we have the option of creating our own type of content and adding the relevant fields. In addition, each of these content types can have its own views that have different sets of fields. I know, I know - it seems complicated, but I'll give you a quick example to help you understand it better.

People in the team - an example of content creation

Imagine that you would like to have a content type of "People in the team". Furthermore, you state that you would like to present this information as a list of all employees and have a specific person page with more information. So the data structure could look like the following:

View 1 - listing of people

• name,
• image
• role in the team.

View 2 - person details

• name,
• image,
• role in the team,
• description.

Drupal will allow you to create two different views, the second of which will have an additional field. The views will be displayed depending on the context. Pretty cool, right? And all this without any additional modules.

View 1 - listing of people - view displaying all employees in the company

Field configuration in the CMS - View 1

View 2 - person details - single-page view

Field configuration in the CMS - View 2

Well. We're chatting here, but how does one end up adding this content? Is it simple, or is it complicated? Actually, it all depends on the number of fields we have to fill in. In our case, adding a new person will involve filling in a few areas on the form. Projects, however, often use the Paragraph module to create components. These components can then be embedded in your content type. This approach allows you to build the page in a more block-based manner. Unfortunately, this often involves completing many more fields and can sometimes be time-consuming.

I show below what this might look like in the standard view.
 

Standard content addition for content type Person

Whether you want to create a simple system or a very advanced one, in Drupal, everything is based on modules. Even the standard ones that come with the Drupal package are not always included (such as language management modules).

The people responsible for Drupal adopted a modular model to create this system. This means that a module is responsible for individual functionalities. This approach brings us many advantages:

• It is much easier to control the code when it is divided thematically, and each module is responsible for itself,
• It is easier to add new features or fix bugs,
• We can create our own modules to create new functionalities or extend existing ones,
• We can modify the code of the modules or rewrite them, which could lead to a 'disaster' at a later date. For example, imagine that in six months some functionality in the main code changes. Unluckily for you, it has affected a module you overwrote or rewrote for your own purposes. At this point, it becomes challenging to update the software because you have to go through all your code and improve it in the same way they did with the original module.

You'll have to take my word for it: I was faced with a situation where the source codes were overwritten, and our task was to upgrade Drupal to a higher version, and such "code straightening" took us several weeks. If the code had been written correctly, it would have taken much less time, and the client would have saved a lot of money.

Modification of the extended module

OK, but what if you have done it correctly, and instead of overwriting, you have simply extended the capabilities of the module, and it has just changed slightly? Of course, it's worth looking at what changes have been made, which doesn't mean you'll have to change anything yourself. Drupal has a lot of good practices. The code doesn't change just like that. There are procedures for this, where first, the code is marked as "deprecated", and your IDE environment like PhpStorm will tell you what to remove. Additionally, Drupal has pervasive comments next to methods, so you'll know what it's for and what to do with it.

Adding a module

There are several ways to add a module in Drupal:

1. Programmers will definitely choose the Composer option,
2. CMS managers will need to download the package from the Drupal repository and upload it via the CMS. 

I know I know, the second way is not super convenient because you have to go to drupal.org, find the module, download it or copy the link, log in to the CMS, go to the appropriate tab and upload it to our CMS. A lot of work.

However, Drupal developers in the latest version, which is Drupal 10, are planning to add functionality which will enable us to install a module directly from the CMS level. We can see such a solution in WordPress, among others, and I must admit that from the customer's point of view, it is a very convenient solution.

If you have reached this point and I have aroused your curiosity, I will be very pleased. In this paragraph, I will introduce you to the principle of building modules in Drupal.

As I mentioned earlier, when creating pages in Drupal, you will have to write your module sooner or later. While the creation of templates is relatively straightforward, modules - in order to do them correctly, according to accepted standards and conventions - already require much more knowledge of Drupal. I have seen projects like this where the client used Drupal, but the modules were created according to Symfony conventions, making the project much more challenging to manage. Don't get me wrong: I'm not saying that these modules were badly written, quite the contrary. On the contrary, they didn't conform to the Drupal convention, making it necessary to do some strange hacks and workarounds. But, hmmm, a thought may have occurred to you now - well, after all, you said Drupal is built on Symfony, so what's the point? Yes, that's true, but in order to create a CMS, it has adopted its own assumptions and standards in order to make it possible to build advanced CMS based systems in it.

All right, but what about these modules, are they easy to create or not? The answer here is, as usual, ambiguous. For people who are very familiar with object-oriented programming, creating modules will certainly come much easier than for people who write more structured code, such as in WordPress. In addition, you need to be well-versed in the Drupal structure itself to get going.

For example, in order to create a certain functionality, you need to know which class to inherit from or which interface to implement (why reinvent the wheel). Of course, it is possible that you will have to deal with such a module, which will be typically unique, and you will not use already existing classes or interfaces, but I know from experience that most of your programming tasks will be based on this.

This is because Drupal is a CMS that can be perfectly extended using the code that already exists. By knowing certain principles, you will see that over time you will do many things automatically.

In conclusion, is writing your own modules difficult? The answer is that it is not one of the easiest tasks, as it requires a lot of knowledge of the entire ecosystem. On the other hand, writing the code itself is very pleasant due to the fact that the object-oriented style prevails here, and the methods and their parameters are perfectly described.

For example, building a module that allows you to embed social icons as a block should not take more than 2h for a moderately experienced person. On the other hand, building a module that allows you to construct a multistep form may even take several days.

On the official Drupal website, as was the case when building your own themes, you can find a manual on how to build your own module step by step.

We have discussed some general issues regarding popularity and content management. Now it's time to delve a little deeper into the technical aspects. If you are familiar with PHP, CSS, JS and HTML, you can safely start working on building your own theme. But before we get into that, let's answer the question: what is a theme in Drupal anyway? It is nothing more than a template for our website. It is what is responsible for the visual part of our site and the interaction with the user. 

At the very beginning, it is worth noting that Drupal is based on the Symfony framework, which - by default - uses Twig to create templates. Does this mean you need to know Symfony before you start working with Drupal? Not necessarily. Of course, it is very good how you know the basics and some of the essential components of Symfony. This will make Drupal concepts much easier for you to understand, and it will be much easier for you to create both themes and modules in Drupal. On the other hand, you should be familiar with Twig when building themes. It is essential here if you want to use the default template engine. Of course, Drupal has a module that exposes an API, so when creating a so-called headless theme, you can ditch Twig and create themes in a library of your choice, such as React.

How do you go about building a theme?

Building the theme itself is not too complicated. It usually consists of overwriting already existing templates and, if necessary, passing additional variables to them using so-called hooks. What are these magic hookups? They are nothing more than functions into which you can - colloquially speaking - plugin and modify values, which are passed to a specific template at the very end.

I encourage you to explore this topic further and visit the official Drupal website here, where a step-by-step demonstration is given of what this looks like.

In this comprehensive article, I've given you a literally tiny snippet of what Drupal can do. There are many more aspects, such as performance, graphics optimisation, security, environment configuration and much, much more. I would have to devote a few or several articles of this length to content management alone in order to more or less exhaust the subject and give you a wealth of knowledge and insight.

What I like most about Drupal is:

• flexibility - you can create your own content types or views depending on the context in which you want to display them.
• extensibility - creating modules due to the object-oriented style of programming.
• good practice - there is order in the code, and it is very easy to see the specific methods used because of the extensive comments.
• good documentation.
• user interface - although it is not too beautiful, it is very practical, making it very easy to configure the content.
• standard modules - these cover a lot of the functionality you need to build small and medium-sized sites, so you don't need to look for additional modules.
• large community - most of the solutions to the problems we encounter can easily be found on the web, so we do not have to reinvent the wheel.
• multisite and multilingual - these are built into Drupal's core, making it ideal for enterprise-class solutions as well.

As you can see, the list favouring Drupal is quite large. I have to admit that the transition from the WordPress world to Drupal was not an easy one because of the:

• speed of code development, 
• the number of available modules,
• popularity,
• a user-friendly and minimalist interface.

However, when building something more than a landing page or a standard business card with a few sub-pages, I would definitely recommend Drupal as the target CMS every time.

By this article, I just wanted to arouse your curiosity, and who knows - maybe it will make you more interested in the CMS in question, which I warmly encourage you to do. Also, look out for more articles about it :)