Open source - a world of give and take
Modules are ways to organise functionality (and code) into packages. Almost all software systems are modular ‘under the hood’ but some are better than others in defining how they are structured and how they interact with the core system and with each other.
Drupal has always had the advantage of a clearly defined architecture for modules, and strict rules for how they extend or alter the functions of other parts of the system.
As we will explore in this article, these clear definitions have been key to Drupal’s success, allowing countless numbers of developers to build out new functionality without compromising the quality of the core Drupal code.
And, as we will discover, the technical structure of Drupal Modules combined with an open culture, processes of code review, and a platform to release code into the community, has resulted in development effort being focussed into areas of common need.
Know your modules: Core, Contrib and Custom
There are three types of Drupal modules - Core, Contrib (short for contributed) and Custom - sitting in interlocking layers that defines the way they interact. With all three types, the packaging of functionality and the code architecture are the same, but the community review processes around them differ.
Core modules sit in the centre, providing all the essential functionality of the content management system as well as a framework for adding more. When you ‘download Drupal’ from Drupal.org, it is this core functionality and code that you receive. Being key to the functioning of literally millions of websites, modules that are downloaded as part of Drupal core are carefully reviewed by the community and also tested for security.
Contributed modules are published on and distributed via the Drupal.org and provide additional functionality. However, they do so without changing any core code. Instead they alter or extend core behaviour via ‘hooks’ and they may themselves provide hooks so that their own functionality can, in turn, be changed by other modules.
Contributed modules have maintainers who oversee changes and they are reviewed by module users, but they are not as subject to such rigorous checks as core modules. If security issues are found, notice of updates are circulated to Developers who subscribe to security alerts.
The third type, custom modules, also use ‘hooks’ to interact with core and other contributed modules. However, these generally implement bespoke functionality for a particular site and review processes are very much down to the developers who created them.
An example of modules working together
While a simple website may only provide a straightforward login for its editors, the site we are building for RCPCH is much more complex.
RCPCH users must log in via a ‘single sign-on’ (SSO) provider who ensure that authenticated users can also access external, partner sites. Once authenticated by SSO, login to Drupal is not complete until their CRM is queried to find out the role of the user.
Helpfully, the core user login functionality provides a ‘hook_user_login’ which other modules can use to alter the login process.
In this instance, we rely on a contributed module (simpleSAMLphp Authentication) for the SSO login. This module provides all the functionality needed for talking to external SSO providers.
Alongside this contrib module, we have created a custom module to retrieve user roles from the CRM via its API, which then makes use of a hook provided by the simpleSAMLphp Authentication module to insert itself in the login process - adding the user role as login is completed.
Hooks - how modules interact
The example above shows how Open Source code nests together and crucially, how new functionality can be added without compromising the integrity of other functionality.
The first rule for any new Drupal developer to learn is ‘Don’t hack core’. This is a shorthand way to say never compromise core or contributed modules with direct changes. Instead, build your own ‘helper’ modules and use hooks to modify the behaviour of other modules.
The importance of this cannot be overstated - hacks to core or contributed modules means that they cannot be updated and their tried and tested behaviour cannot be relied upon.
On the other side of the coin, module maintainers must ensure that whatever changes they make to their modules, the ‘hooks’ must remain the same. In this way, modules can develop along their own pathways without upsetting the modules that interact with them.
The other C - ‘Community’
‘Generativity’ is a term used to describe how some technologies enable new services to be built on top of them - often to do things that the original developers never imagined.
Drupal is a fantastic example of generativity and, as we have seen, the technical structure of modules encourages and enables rapid development, which in turn encourages developers to work with it - creating a virtuous circle and powering a huge global community.
Drupal has always embraced the Open Source dictum to ‘release early and release often’. Releasing code for the use and scrutiny of other developers is key to the success of Open Source as a whole.
Security is one of the areas where having many eyes on code, which, without restriction, provides better identification of issues. And releasing early into the community also means that efforts at solving early problems are distributed - leading to clusters of effort naturally targeted around specific problems or sectors.
‘Release early and release often’ also means that some modules may be in a rough and ready state early in their lifetime. However it also means that issues are likely to be identified and solved rapidly and the overall quality of code quickly improves.
Investing in a Drupal project means being a beneficiary of the immeasurable effort of the entire Drupal community. The technical structure of Drupal modules and the ‘Release early, release often’ principle has led to a fantastic array of tools to meet the needs of many sectors. Added to this, you get a framework that allows your own customisations to be created, while still benefiting from the stability of the wider framework.
In return, commissioners need to understand that contributed modules may sometimes be at early stages of development or recently released and not fully stable. Developers on your own site may contribute to these; benefitting all users in the longer term and making it more likely that tools you used are better developed and maintained in the future.
But it is a world of give and take - the software is free, but sometimes it isn’t perfect and sometimes unfinished. You own developers need time to navigate that space, and sometimes the work they do is not just for you, it is for the benefit of others too.
It is, as we said at the beginning, a world of give and take.