Technologies that drive Drupal

Installing Drupal 8 in the traditional way is documented both on Drupal.org and in the INSTALL.txt file found inside the /core folder of the installation, so I won't go into it here. I will, however, mention that a better way of installing Drupal 8, especially for developers, is by using the accepted Composer template for Drupal 8 projects found on GitHub (https://github.com/drupal-composer/drupal-project). However, the instructions for setting up your site are well covered there as well.

Instead, let's talk a bit about the technologies that power (or are needed by) Drupal 8.

PHP

Drupal is written in the PHP programming language. PHP is a widely supported, multiplatform, and web-centric scripting language. Since Drupal is written in PHP, this book will largely feature code written in PHP, albeit with Drupal standard practices being kept in mind.

It is very important to note that the minimum version of PHP required for Drupal 8 to run (and install via Composer) is 7.1. Therefore PHP 5 is no longer supported, neither by Drupal nor by the PHP community at large. By the time you read this book, you should probably be running Drupal on PHP 7.3 or at least 7.2

Regarding the style of PHP, a very important change compared to Drupal 7 is the heavy use of object-oriented code and design patterns. Granted, many procedural style approaches remain throughout the Drupal 8 code base, but the use of a good number of popular external libraries (such as Symfony components) has pushed the overall Drupal code to be more modern. For this reason, it is also quite important that you have at least some basic understanding of Object-Oriented Programming (OOP), especially PHP-related, if you want to do Drupal 8 development.

Databases and MySQL

In the past, Drupal has supported two databases—MySQL and PostgreSQL. Drupal 7 and 8 have moved beyond this. Drupal now uses the powerful PHP Data Objects (PDO) library that is standard in PHP 7. This library is an abstraction layer that allows developers to support numerous databases, including MySQL, PostgreSQL, SQLite, and MariaDB.

The minimum database versions for Drupal 8.7 are as follows:

• MySQL 5.5.3/MariaDB 5.5.20/Percona Server 5.5.8 or higher with PDO and an InnoDB-compatible primary storage engine
• PostgreSQL 9.1.2 or higher with PDO SQLite 3.7.11 or higher
• SQLite 3.7.11 or higher

Additionally, Drupal provides a powerful database API along with SQL coding conventions that make it easy to interact with your database—which, combined, allow you to write safe and portable SQL. However, more and more abstractions have been made at different levels, removing the need for SQL writing almost completely. However, we will still see some examples just so your toolbox does not miss anything, as well as cover all the tools at your disposal for querying your database.

The web server

Apache has long been the predominant web server, but it is by no means the only server. While Drupal was originally written with Apache in mind, many other web servers (including IIS, Lighttpd, and NGINX) can run Drupal.

We do not explicitly cover the web server layer anywhere in this book, primarily because development rarely requires working at that low level. However, Drupal expects a fair amount of processing from the web server layer, including the handling of URL rewriting. For more information on what you can expect, you can consult the relevant documentation page at https://www.drupal.org/docs/8/system-requirements/web-server.

HTML, CSS, and JavaScript

The de facto web data format is HTML styled with Cascading Style Sheets (CSS). Client-side interactive components are scripted with JavaScript. As Drupal developers, we will encounter all three of these technologies in this book. Although you don't need to be a JavaScript ninja to understand the code here, you will get the most from this book if you are comfortable with these three technologies.

Drupal architecture

In the preceding section, we introduced the technologies that drive Drupal. However, how do they all fit together? How is Drupal code organized? In this section, we provide an overview of Drupal's architecture, with a focus on Drupal 8.

Drupal core, modules, and themes

From an architectural standpoint, we can break up Drupal into three pieces: its core, modules and themes.

When we discuss Drupal 8 core, we can interpret it in two ways. A more restrictive interpretation sees it as the functionality covered by all the code it ships with, excluding modules and themes. The more widespread interpretation sees it as the total code base it ships with (out of the box).

Although the most widespread interpretation is the latter (not least because it differentiates all the functionalities its standard installation contains versus all others provided by contributed modules and themes), it is interesting to consider the first one as well, even if just for a minute. Because in doing so we can distinguish, architecturally speaking, the base code from the modules and themes that provide various functionalities and layouts. And why is this distinction interesting? Because at the bridge between the two comes into play the hooks and events that will also allow us to inject ties to our own functionality.

The core libraries are made up of code belonging to the Drupal project and those from the wider PHP community, which Drupal borrows under open source licensing. This latter approach is new in Drupal 8 and has been regarded by many as a positive shift toward getting off the Drupal island and embracing outside libraries, frameworks, and communities.

Essentially, the core libraries provide the functions and services used throughout Drupal. For example, helpers for interacting with the database, translating between languages, sanitizing user data, building forms, encoding data, and many such utilities are found in Drupal's core libraries.

The modules (both core and contributed) are where most of the actual business logic is encapsulated. If enabled, they can provide functionality or extend the existing one. Most of the core modules are needed and cannot be disabled due to their importance in the standard Drupal installation. However, contributed ones can be installed and uninstalled as needed.

The themes (both core and contributed) are an important part of the theme system and are used by the presentation layer. They provide HTML templates within which content and data can be rendered to the user, as well as CSS styling and even client-side scripting for some nice visual interactions. Themes can extend other themes and can also contain some PHP logic to process the data before being rendered.

Hooks, plugins, and events

Now that we have seen what the core libraries, modules, and themes do, let's talk briefly about hooks and events to understand how they are all connected.

Hooks are a very typical Drupal procedural concept that allows Drupal core and modules to gather data from other modules and themes (or expose it). By doing this, the latter can provide new functionality or alter existing ones. It is the responsibility of the code that invokes the hook to make use of whatever the hook implementations return. The format for whatever the latter need to return is usually described in the hook documentation.

Concretely, hooks work by scanning installed modules and themes and looking for a function that follows a specific naming pattern (in other words, a hook implementation). This is, in most cases, in the following format—module_name_hook_name. Additionally, there are also alter hooks, which have the word alter tacked on the end of the function name and are used to change data passed as a reference to the hook implementation. We will see examples of hooks later in the book.

Developers with a background in OOP or with a strong knowledge of design patterns might recognize this as being similar to the event handling paradigm captured in the Passive Observer pattern. When some particular event occurs, Drupal allows modules the opportunity to respond to that event.

In previous versions of Drupal, hooks were KING. Yes, I wrote this in capital letters; my Caps Lock did not get stuck. This is because they were the way to add or extend functionality in modules. As such, they were the single most important aspect of Drupal programming. In Drupal 8, however, although still important, they took a backseat to new concepts, such as plugins and events.

In Drupal 8, I dare to say that plugins are king. Much of the logic that used to be tied to Drupal via hooks is now added in through plugins (not to be confused with WordPress plugins). Drupal 8 plugins are discoverable bits of the functionality centralized by a manager and that are used for certain tasks and features. We will see more about plugins and provide many examples later in the book.

A third extension point introduced in Drupal 8 is the event system. Unlike the first two, however, this is not specific to Drupal, but is, in fact, the actual Symfony EventDispatcher component (http://symfony.com/doc/current/components/event_dispatcher.html). Events are primarily used in Drupal to intercept certain actions or flows in order to either stop or modify them. Many request to response tasks that were handled via hooks in the past are now being handled by dispatching events to check whether any modules are interested in, for example, delivering the response to the user.

Services and the dependency injection container

Another architecturally important element of Drupal 8 is the Symfony dependency injection component (http://symfony.com/doc/current/components/dependency_injection.html), specifically represented by the service container.

This component is a staple of modern OOP PHP programming and as such has become foundational to Drupal 8. It allows us to create services that can be injected in various places of our code in order to handle certain functional (and oftentimes swappable) tasks. Additionally, they can also be used as an extension point because the service container is able to group services that have very specific responsibilities and use them for that automatically. In other words, simply by defining a simple service, we can provide our own functionality or even change existing logic.

We will encounter many services, and we will see how we can declare our own later in this book.

From request to response

Now that we have listed the most important architectural pieces of Drupal, let's briefly see how these are used in delivering responses to the requests a user makes on a Drupal 8 website. To this end, we will analyze a simplified example of a request as it is handled on a Drupal 8 website:

1. A user accesses the http://example.com/node/123 URL in a web browser.
2. The browser contacts the web server at example.com and requests the resource at /node/123.
3. The web server recognizes that the request must be handled by PHP and starts up (or contacts) a PHP environment to handle the request.
4. PHP executes Drupal's front controller file (index.php), which then creates a new Request object from the resource that was requested.
5. Symfony's HTTPKernel handles this request object by dispatching a number of events, such as kernel.request, kernel.controller, kernel.response, and kernel.view.
6. The route that maps to that request is identified through the kernel.request event.
7. The route controller is identified, and the kernel.controller event is used to perform any alterations on the responsible controller, as well as to resolve the arguments that need to be passed to it. In our case, this route is registered by the Node module through the main Entity system, which identifies the entity ID, loads it, and builds the markup to be returned as part of the response.

8. If the respective controller (or handler) returns something other than a response object, the kernel.view event is dispatched to check whether there is any code that can transform that into a Response object. In most cases, in Drupal 8, we typically return render arrays, which are transformed into Response objects.
9. Once a Response is created, the front controller returns it to the browser and terminates the request.

In this context, as Drupal 8 module developers, we spend most of our time inside controllers and services, trying to figure out what we need to return to the page. We then rely on Drupal to transform our render array into a proper response to the user, but we can also return one ourselves directly. Moreover, the theme system comes into play here, as well as the block system, because our content gets wrapped into a block that is placed in a region surrounded by other regions that contain other blocks. If it sounds complicated now, don't worry; we will cover in detail all these aspects with examples, and it will become clear in no time.

Drupal's major subsystems

In the previous we took a bird's-eye view of Drupal's architecture. Now, we will refine our perspective a bit. We will walk through the major subsystems that Drupal 8 has to offer.

Routing

It all starts with a route, doesn't it? Most interactions with a Drupal 8 website begin with a user (or system) accessing a certain path (or resource). This translates into a route, which maps that resource to a flow that (hopefully) returns a successful response back or at least a graceful failure.

The Drupal 8 routing system is a major shift away from how it used to be in its previous versions. In Drupal 7 and before, the routing system was a very Drupal-specific thing (a drupalism, if you will). Many of us remember hook_menu as a staple hook each Drupal developer had to know very well. All of that has been abandoned in Drupal 8 in favor of the Symfony Routing component (http://symfony.com/doc/current/components/routing.html). Also, since I mentioned hook_menu, I will also mention that its other main functions have also been taken over in Drupal 8 by other subsystems, such as plugins.

In Chapter 2, Creating Your First Module, we will see how we can define our own route and map it to a controller that will render our page. We will cover a few of the more important route options and take a look at how we can control access to these routes.

Entities

Progressively, entities have become a very powerful way of modeling data and content in Drupal. The most famous type of entity has always been the Node, and it has been historically the cornerstone of content storage and display. In Drupal 8, the entire entity system has been revamped to make other entity types potentially just as important. They have been brought to the forefront and have been properly connected with other systems.

All entity types can have multiple bundles, which are different variations of the same entity type and can have different fields on them (while sharing some base fields).

Drupal core still ships with the Node entity type, with a few bundles such as Basic Page and Article in its standard installation profile. In addition, it comes with a few other entity types, such as User, Comment, and File. However, creating your own entity type in Drupal 8 has become much more standardized compared to Drupal 7 where contributed modules had to be brought into play.

These are not the only types of entities we have in Drupal 8. The aforementioned examples are all content entity types. Drupal 8, however, also introduced the configuration entity types. The former are for modeling content, but in reality, they are for anything that holds data that can be stored in the database and is specific to that environment. They are not used for storing configuration, though. Users and content are great examples, as they do not need to be (usually) deployable from one environment to another. The latter, on the other hand, are exportable items of configuration, of which there can be more than one. For example, a content entity bundle is a great example because there can be more than one bundle for a certain entity type; they have some metadata and information stored that can differ from bundle to bundle, and they need to be deployed on all environments. That is, they are fundamental to the correct functioning of the site.

Understanding the entity system is indispensable for doing development in Drupal 8 because it provides a powerful way to model custom data and content. Nodes are not the only tool for the job and in my opinion, they were used in previous Drupal versions way past their purpose due to the lack of a proper entity architecture.

Fields

Now that we have an idea of what entities are, let's take a look at how data is actually stored on these entities.

I have alluded in the preceding section to how certain entity bundles can have various fields. This means that each entity type bundle can have any number of fields that are responsible for holding data. Additionally, each entity type itself can have fields for storing data. Okay, but what? Let's break this down.

There are two types of fields in Drupal 8—base fields and configurable fields. The former are fields that are defined in the code for each entity type, whereas the latter are usually created and configured in the UI and attached to a bundle of that entity type (and exported via configuration).

Fields can also be of multiples types, depending on the data they store. You can have string (or text) fields, numeric fields, date fields, email fields, and so on. As developers, we can create our own field types if the existing ones are not good enough for our data.

In this book, we will take a look at how we can define base fields on a certain entity type and create our own field type with its own data input widget and output formatter. Site builders can then use this field type on any entity type.

Menus

Any site needs some sort of navigation, right? Drupal not only maintains content, but also provides details about how the site itself is organized. That is, it keeps a structure of how content is related.

The principal way that it does this is through the menu subsystem. The latter provides APIs to generate, retrieve, and modify elements that describe the site structure. Put in common parlance, it handles the system's navigational menus.

Menus are hierarchical, that is, they have a tree-like structure. A menu item can have multiple children, each of which may have their own children, and so on. In this way, we can use the menu system to structure our site into sections and subsections.

In this book, we will see how we can work programmatically with menus and menu links.

Views

Listing content and data is always an important capability content management systems covet; and this is what Views does in Drupal 8. And it does it well.

If you've been building (not even necessarily developing) sites in previous versions of Drupal, you'll understand everything with this simple phrase—Views is now in Drupal core.

If you haven't, Views has always been a staple Drupal contributed module used on probably all Drupal installations (to a certain extent) and is an indispensable tool for site builders and even developers.

The purpose of the Views module is to expose data and content in a way that allows the creation of configurable listings. It includes things such as filters, sorts, display options, and many other features. As developers, we often find a need to write our own field or filter plugin to work with Views or expose data from our custom entities or external data sources.

Views is a core Drupal 8 module tied to the general architecture and used for most list pages (especially, admin pages) provided by Drupal core. Although it's a very site building-oriented tool, in this book, we will take a look at how we can create plugins that extend its capabilities to offer site builders even more.

Forms

Unless your site has three pages and five paragraphs of text, the likelihood that you will need to capture user input via some type of form is very high. Also, if you've been coding PHP applications you know how forms have always been a pain from the point of view of securely and efficiently rendering and processing the submitted data. As soon as you use a PHP framework such as Symfony or Laravel, you will note that an API is in place to take much of that load off your shoulders.

The same goes with Drupal 8 and its powerful Form API. Historically, it has been a great abstraction over having to output your own form elements and deal with posted values. It allows you to define your own form definition in OOP and handle validation and submission in a logical way. Its rendering and processing is taken care of by Drupal securely, so you don't have to worry about any of that. In Drupal 8, theming form elements has become much easier than in previous versions.

In this book, we will encounter some forms and see how they actually work in practice.

Configuration

One of the major pet-peeves of Drupal developers (and developers of other popular CMSes for that matter) has always been the way configuration is handled and deployed from one environment to the next. Drupal 7 stored most of its configuration in the database, so various solutions had to be concocted by developers to get that moved up the ladder as development progressed.

In Drupal 8, great advancements have been made in this respect with the introduction of a centralized configuration system. Although it stores all configuration in the database, it allows it all to be exported into YML files (and then reimported). So, from a development point of view, we have a much better experience if certain features depend on configuration (for example, a new field).

Configuration is also of two kinds—simple and complex (configuration entities we noted in the Entities section). The difference between the two is that the former is always singular. In other words, there is only one instance of itself. For example, the site name and email address are stored inside such a configuration item. You wouldn't expect the need for more than one instance of it. However, in the case of the latter, you would. For example, a View definition is such a configuration entity because it follows a certain schema and we can have multiple View definitions. Makes sense doesn't it?

Plugins

Plugins are new to Drupal 8 and are an elegant solution to an important problem— encapsulating functionality. Right off the bat, you should not confuse them with things such as the WordPress plugins, which are more akin to Drupal modules. Instead, you should think of plugins as components of reusable code that can be used and managed by a central system. Typically, they are used when a system handles a task in a certain way (plugin A) but allows other modules to provide different ways to handle that task (plugin B or C).

You can also look at plugins as being opposite to entities: not used for data storage, but for functionality. Instead of creating a type of data that gets stored, you create a type of functionality that is used. The two usually work hand in hand, especially when it comes to manipulating the data in different ways.

An important aspect of how they work is their discoverability. Most plugin types (but definitely not all) are discovered via something called Annotations. Annotations are a form of DocBlock comments, borrowed from the Doctrine library (http://docs.doctrine-project.org/projects/doctrine-common/en/latest/reference/annotations.html), by which we can describe classes, methods, and even properties with certain metadata. This metadata is then read to determine what that item is without the need for instantiating the class. In Drupal 8, we use annotations only at a class level to denote that it is a plugin implementation with certain characteristics. That is how most plugins are discovered in Drupal 8.

The second most common discoverability method for plugins is via a YAML file, and a popular example of those are menu links (as we will see later in the book). However, for now, you should know that plugins are very widely used, and we will create quite a few plugins in this book.

Plugins are a great new extension point for developers to add their own functionality and are a critical subsystem in Drupal 8. Every Drupal 8 developer needs to be comfortable with the plugin system.

The theme system

The responsibility for theming a given piece of data is spread out over the Drupal core, modules, and the themes themselves. So, as a module developer, it is important to know that both modules and themes can theme data or content.

In this book, we will focus on the aspects that happen at the module level. We will not concern ourselves with styling, but work primarily with theming definitions and templates that are needed within the module. Typically, it is best practice to ensure that modules are able to theme their data. If done right, themes can then come into play to style the output or override that theming to change the presentation altogether.

A major shift in Drupal 8 compared to older versions is the move to the open source Twig templating system (https://twig.sensiolabs.org/). This makes the separation of logic from a presentation that much clearer and makes frontend developers jobs much easier, not to mention more secure.

Caching

The last major subsystem that I will include here is the caching layer. Drupal 8 has gone to great lengths to improve the performance of building pages and rendering data. To this end, the caching system has become an important part to consider whenever we either do complex or heavy calculations or render content.

From a module developer's perspective, there are two main pillars of the caching system. The first one provides developers with a cache backend to store the results of complex data calculations. This can be read in the next requests to avoid the need for reprocessing that task. This goes hand in hand with the cache invalidation that happens when something in the system changes that would require the calculations to be redone. The second pillar is the render cache, which allows developers to wrap their output with metadata that describes when the cache of that output needs to be invalidated.

We will see these in action in a later chapter dedicated to caching.

Other subsystems

There are other subsystems in Drupal 8 of varying importance. I chose to include the previous ones because I deemed them to be the most important to be introduced up front and especially from the point of view of a module developer. However, as we progress through the book, we will definitely encounter others.

Tools for developing in Drupal

Drupal is a sophisticated platform, and from the glimpse provided in this chapter, we can already see that there are numerous systems and structures to keep track of. In this section, I will provide tools that simplify or streamline the development process.

Going forward, I assume that you have your own web server stack and your own PHP development tools. However, if you are just getting started, you may want to look at Acquia Dev Desktop from Acquia (http://acquia.com). It offers entire application stacks to get you started on Windows, Linux, or macOS X. Alternatively, if you are even just a bit more advanced, you can consider the Drupal VM (https://www.drupalvm.com/), a Vagrant and Ansible-based local development environment ready for Drupal.

Finally, the most flexible development environment in my opinion is the Docker-based one. You can easily get started with a pre-made and well documented stack here: https://github.com/wodby/docker4drupal.

As for a code editor, I personally use PhpStorm (as many others do), but you are free to use whatever IDE you want because Drupal itself doesn't require anything special. Do, however, use some sort of an IDE because it will make your life much easier.

Additionally, while running a PHP debugger is certainly not necessary, you may find running Xdebug or the Zend Debugger to be useful. I personally recommend a PHP debugger wholeheartedly, not only for debugging itself, but also for understanding the processes that happen under the hood.

Version control

Any software development needs to happen through a version-controlled environment. By now, Drupal is universally using Git. So, you should make sure that you have Git installed locally, even if just to be able to check out the code examples we write in this book, which are hosted on GitHub.

Composer

As I alluded to earlier, installing Drupal 8 is best done via the Composer template project. However, you may also install it straight from Git by checking out the latest tag or commit in the Drupal.org Git repository (https://www.drupal.org/project/drupal/git-instructions). If you do this, you will need to install its dependencies via Composer, and Drupal has many.

To this end, you will need to have Composer available on your development environment and have a basic understanding of how to use it.

The API site and coding standards

A lot of background knowledge is required for writing good Drupal code. Of course, the aim of a book such as this is to try to provide as much of that background knowledge as possible. However, self-documentation and research still remain key, and there are a number of resources that a Drupal developer should have on-hand.

The first is the official online API documentation. Just about every function in Drupal is documented using inline code documentation. The Doxygen program is then used to extract that documentation and format it. You can access the full API documentation online at http://api.drupal.org.

Along with using the Drupal APIs, we strive to comply with Drupal's coding conventions. Best practices in software development include keeping code clean, consistent, and readable. One aspect of this is removing nuances in code formatting by following a fixed standard.

This is particularly important on a platform such as Drupal, where thousands of developers all contribute to the code. Without coding standards, the code would become a cluttered mishmash of styles, and valuable development time will be spent merely deciphering code instead of working on it.

The Drupal site has a manual on coding standards that each Drupal developer needs to become familiar with (https://www.drupal.org/docs/develop/standards/coding-standards). It won't happen overnight; you will get better with experience, but you can also configure your IDE to, for instance, flag any issues with your code formatting.

A third resource for developers new to Drupal 8, but who have experience with Drupal 7, is the change records database (https://www.drupal.org/list-changes/drupal). On this page, you'll find an inventory of the most important API and usage changes with some handy explanations that will be extremely helpful for Drupal 7 developers looking up how certain functions have been changed.

The developer (Devel) module

On your development environment, you can install a handy module called Devel (http://drupal.org/project/devel), which provides several sophisticated tools designed to help developers create and debug Drupal code.

The following are a few of the features of this module:

• Functions used for dumping objects and arrays into formatted Drupal output
• Tools for analyzing database usage and performance
• A content generator for quickly populating your site with testing content

Drush (the Drupal shell)

Sometimes, it is much easier to run some tasks with a single command in a console. Drush (http://drupal.org/project/drush) provides a command-line Drupal interface and it can be used to execute tasks with a few keystrokes at the console.

When developing, we often have to clear caches, run specific tasks, or deploy data to a remote server. Drush can help accomplish tasks like these. Additionally, we can write our own Drush commands that perform various custom tasks, for example, to be used in cron jobs. So having Drush installed is a must for any serious Drupal developer.

Drupal Console

If Drush is a tool that has been around for many years, the Drupal Console (https://drupalconsole.com/) project is new to Drupal 8. Its purpose is similar to that of Drush, and in this way, it complements it, if at times even overlaps with it. However, one thing is clear—its scope is much broader, especially in its handy commands that generate boilerplate code, which can get quite lengthy.

Although we won't be using this tool in this book, it's recommended that you install it as you progress with learning Drupal 8 module development and start generating certain code structures faster. That being said, I advise caution in using it at the expense of actually understanding what the code it generates actually does. Always strive to understand what you are doing, and never give in to blindly copying and pasting code from Stack Overflow or any other resource without grasping fully what it does.

Developer settings

While doing local development, it's beneficial to (sometimes) disable things such as caching in order to be quicker. Drupal 8 takes caching to a whole new level, so many hook implementations, for example, get cached. To circumvent this, we can use some local settings that disable caching, prevent CSS and JavaScript file aggregation, and do similar things.

These settings are found inside the example.settings.local.php file in the /sites folder of the installation. To benefit from these, you will need to make sure that they are included in your main settings.php file (either by copying them inside or including a file such as this).

A word of caution—do keep in mind that by developing with caching disabled at all times, you run the risk of overlooking certain aspects that won't work properly with caching enabled (such as invalidations). So, do try to toggle these settings on or off to ensure a production-like environment will work just as well as under your development conditions.