In part 1 of this series we introduced Drupal from the perspective of an enterprise architect. In part 2 we took a deeper dive into aspects of Drupal’s software architecture.Now we understand a bit more about Drupal from a conceptual level, let's take a look at its components and code.
Types of components & code organization
The Drupal project itself is composed of two parts: the core and contributed spaces. These live on drupal.org where they can be downloaded, and issues filed. The issue queues there are also searchable and you can view usage statistics over time to get a greater insight into the code.
Core, as you might expect is where the basic Drupal software as you would normally download it is created. This includes core modules covering base functionality, a small set of themes, and the underlying framework.
The contributed space consists overwhelmingly of modules, themes, and distributions. (There are just a few exceptions, such as Drush - Drupal’s CLI utility, and the apps format.)Drupal core provides basic functionality out of the box and the codebase is tightly controlled. Core is by definition a slow moving and stable project. Whilst everybody is encouraged to contribute code to core, there are only a small handful of people who can actually commit that code and any changes are subject to an extremely high degree of scrutiny and discussion. In addition, there is a volunteer team who assist with security issues.
The Drupal community is also encouraged to contribute new components which extend Drupal’s functionality, and these live in the contribution space on drupal.org, consisting mainly of modules. These are owned by their respective authors (under the GPL license), who can also work with others as maintainers. By contrast with core, this is a fast moving area of innovation which is essentially free and open to anybody to commit code.
There are two kinds of contributed modules - official and sandbox. Anybody can release sandbox modules and these are generally considered as experimental. In order to release official modules, a developer will have to have their first module vetted and approved by community volunteers, at which point their drupal.org account will be promoted to an official module contributor, allowing them to freely release new modules without approval. This can be quite a lengthy process and will usually involve a few rounds of stringent code review.
While it could perhaps be thought of as a kind of 'driving license for Drupal developers', it should be borne in mind that this is a volunteer-led process and that there is an inevitable backlog.
In addition to helping with core, the Drupal security team will also assist with contributed modules marked as stable.
The Drupal project itself is composed of two parts: the core and contributed spaces. These live on drupal.org where they can be downloaded, and issues filed. The issue queues there are also searchable and you can view usage statistics over time to get a greater insight into the code.
Core
The core codebase essentially consists of a configuration file, a bootstrap, and a set of modules and themes.
The configuration file is quite minimal, mainly setting environmental variables, and Drupal generally uses convention over configuration (as has become standard in many modern web programming frameworks).
There are three areas where the use of convention is particularly helpful: multisite, overriding modules, and extending base themes.
Anatomy of a module
A module consists of a modulename.info file (in Drupal 8 this is modulename.info.yml) and a modulename.module file. Modules can also contain a modulename.install file, a modulename.test file, and a theme directory containing templates.
Required module files
modulename.info or modulename.info.yml file
The info file is a text file containing basic information such as the name, version, and dependencies of a module. In Drupal 8, the YAML-based info file can also contain configuration data.
modulename.module file
The module file is a PHP file containing a set of functions which either react to event hooks in the system, or provide their own as extension points to other modules. The module file will also typically contain internal functions which are intended as equivalent to private classes or methods in OOP (the convention is to preface these with an underscore), and file includes. A common pattern is to write PHP classes as separate include files, keeping the .module file minimal and acting as a kind of interface.
Optional module files
modulename.install file
The install file is used to perform actions when a module is installed, uninstalled, and upgraded. The most common use of this is for creating or altering database tables, but as a PHP file it has access to Drupal’s full API.
modulename.test file
The modulename.test file contains tests which will be automatically picked up by Drupal’s Simpletest framework. These can include unit and functional tests.
modulename.routing.yml file
Drupal 8 modules also typically include a modulename.routing.yml file for routing. (In Drupal 7 and below, routing was handled by the internal hook_menu function within the .module file.)
theme directory
An optional theme directory will contain templates providing default markup and styling for any output produced by the module. This may also contain a PHP file providing theme functions, which are extension points allowing the markup to be picked up and overridden by a site’s theme.
Themes
In Drupal 7 and below, Drupal themes use Drupal’s own PHP-based templating system. In Drupal 8, Symfony’s Twig templating system has been adopted.
Themes can declare other themes as base themes and just add or override parts of them. This is a very useful pattern when using standard themes such as Twitter bootstrap.
Anatomy of a theme
Themes consist of a themename.info file (Drupal 8: themename.info.yml), an optional template.php file (Drupal 8: themename.theme), and a set of .tpl.php files (Drupal 8: .html.twig files).
themename.info or themename.info.yml file
The info file defines things such as javascript files, layout regions, and style sheets.
template.php or themename.theme file
The template.php file (Drupal 8: themename.theme) is used for logic and data processing and helps to keep template files clean and free of logic.
.tpl.php files
In Drupal 7, the template files should consist of HTML and PHP variable placeholders. As these files are PHP, there is nothing to stop a person putting any code here and indeed this is a very common anti-pattern to watch out for.
.html.twig files
In Drupal 8, template files replace these PHP placeholders and control structures with Twig’s syntax, thereby removing this risk.
Tip: This in itself may be a reason for organisations with high levels of regulatory compliance to adopt Drupal 8.
Packages
In practise we find that solution-level functionality is usually built up from a number of lower level generic module configurations (along with entities and their configurations). Drupal has a few ways to package its functionality into bigger building blocks.
Features
A Feature is a special kind of module which packages together modules and configuration to satisfy a certain use-case.
An example of a feature might be a blog or an image gallery and they might be thought of as higher level building blocks within a Drupal solution.
Features are installed and updated just like any other module.
Apps
Drupal Apps are an initiative which have not gained wide recognition within the community but may be of interest to some enterprise users as a packaging and discovery model.
Apps are a higher level and more user friendly variation on Features, with an aim to become as simple to use as the apps found on mobile platforms. Whilst still not widely used, it is possible that Apps will evolve a model for packaging functionality in a user friendly and discoverable way on Drupal 8, which has taken many of the core concepts of Features into core. (See https://www.drupal.org/project/apps for more information.)
Distributions
A Drupal distribution is a packaged installation containing Drupal core, contributed modules, and themes, which is pre-configured to provide a complete boxed solution. While you can recreate the contents of a distribution, they are intended to be quick to install and get you up and running straight away.
Distributions can be used either as a complete solution or as a jumping off point for your own custom solution. A variation for suppliers can be to use distributions either for standardised builds or for capability demos. It’s worth noting that while Distributions are a very fast way to get started, they currently have some limitations when it comes to maintenance.
Having now looked at Drupal’s code organisation we will explore its database schema in the next part of this series of Drupal for enterprise architects.
