When a team is in charge for the first time of the maintenance of a Drupal based project there are always certain questions that arise: "How do I update a Drupal project?" and "When should I update a Drupal project? Although it's easy to find the answer to the first question, there are a lot of doubts about the second one which we'll address in this article.
Why bother
Drupal is a CMS (as powerful as a framework!) based on components: modules, templates, libraries, etc. that are built around a core (Drupal). These components are liable to improvements on functions or security breaches and errors.
The security and stability of your Drupal project are as strong as the weakest of the components that make it up.
List of updates
In order to see the list of components with pending updates, you can visit the URL /admin/reports/updates/update
Types of updates
Security updates
Updates aimed at solving code vulnerabilities. These updates must be the top one priority since it implies a potential risk that could be maliciously exploited.
Drupal counts with a security team that verifies and corrects along with the maintainers of the different modules and core the possible vulnerabilities that get detected. This correction is done privately so that only the security team, the user that has reported the bug and the component's maintainers have access to the vulnerability's information. The main reason is security: if this kind of information were to be published before correcting the incident then it would be easier for malicious users to take advantage of those vulnerabilities to make an attack before a fix is implemented. Once the correction is made, a new version of the software is published, as well as certain details of the problem.
The publishment comes along with scenarios in which the code is vulnerable (the security breach allows an attack) and advises to whose affected projects to update. Given that from this moment, the incident is public, its update must not be postponed for long since automatic exploits may start to arise in the coming weeks and even in the coming hours.
In many occasions, we will be affected by this but updating is highly recommended. Updating should be postponed only when we are 100% sure that we are unaffected and the new update is incompatible with our project. In this last case, we must study it to evaluate if we must wait for a new version, correct with a patch, etc.
Information about the security risk
This information is published in an already established and very compact format that allows us to easily see the risk that this error represents.
The information fields are as follow:
Advisory ID: Unique name.
Project: Name of affected project (core, module name or template).
Version: Affected version.
Date: Date.
Security Risk: Level of severity out of 25 according to the Security Risk Level table.
Vulnerability: Summary of the vulnerability.
Examples
- CORE: Drupal Core - Multiple Vulnerabilities - SA-CORE-2017-003
- VIEWS (module): https://www.drupal.org/project/views/releases/7.x-3.11
- BOOTSTRAP (template): Bootstrap - Critical - Information Disclosure - SA-CONTRIB-2017-048
When are security updates published
The security team has chosen Wednesday (halfway through the week) as the day where the new corrections are deployed, allowing development teams a period for updating projects the same week. It's common for the maintenance teams to schedule some hours on Wednesdays and Thursdays to perform those updates.
If you want to be up to date, subscribing to the Drupal security mailing list is recommended. To do it, we need to have a Drupal account and subscribe in the "My Newsletters" section when editing out the account.
You can also keep up to date by following drupalsecurity on Twitter.
Components covered by the security team
You've probably already seen the following message:
The security notifications are generated only for stable versions of the code (Y.x-Z.0 or higher), excluding development branches such as dev. alpha, beta or rc.
Projects that do not count with a stable version of their code are not actively covered by the Drupal.org security team, so you must take this into account when choosing a component and must remember alway that you can help the maintainer to publish a stable version of the module. You can read more about Drupal's security policy
What does a security update include
Drupal implements improvements and changes in the code along with security updates. If you want to quickly apply the security fix and want to postpone the component's full update, a patch is usually provided on the security issue for fixing the specific error. Remember that applying a security patch is something that must be done provisionally as the recommended option is to install the full update.
New version updates
They are evolutionary updates that improve stability, they add functionalities or refactor certain parts of the code. These updates don't imply a security risk. It's good practice to have the code updated as it may fix errors that we might be having and it favours maintainability of the project in the medium term: cross component compatibility, performance, compatibility with PHP versions, etc.
Examples
- CORE: 8.35
- VIEWS (module): 7.x-3.16
- BOOTSTRAP (template): views 7.x-3.14
Version changes or major updates
We have to be extremely careful with version changes. In Drupal, certain contributed modules can have major changes in the code, this is indicated by version change. For example: 7.x-2.x -> 7.x-3.x.
A major version change can break compatibility with modules that depend on it and are only ready for the previous version. It also includes important changes in the module or template (the main reason for the major version change), so they must be carefully reviewed before applying them.
This is one of the situations in which using Behavior Driven Development (BDD) helps us tremendously: if all tests are executed without trouble then we'll know that at least all behaviours that tests have contemplated continue to work flawlessly.
Summary: When to update
- Security update must be deployed as soon as possible since, as previously discussed, they can solve severe security risks.
- Non-security updates must be studied before to see if they are necessary or not as they can simply add functionality that doesn't matter to us or can fix that annoying bug that we have dragged along since the beginning of the project.
Drupal is a secure CMS that actively takes the necessary measures so it keeps being secure. but it's in your hands to keeps projects updated and free of errors with the tools that Drupal brings us.
