# Drupal security updates

> Drupal security updates guide and best practices.


## Important things to know

- Drupal core and contrib modules security updates are maintained by the [Drupal security team](https://www.drupal.org/drupal-security-team).
- **Security release "windows" are every Wednesday for Drupal contributed projects, and one Wednesday a month (usually the third Wednesday) for Drupal core.** See more at [D.O.: Security release numbers and release timing](https://www.drupal.org/drupal-security-team/security-release-numbers-and-release-timing)
- For Drupal core the **bug fix/feature** release window is on the **first Wednesday of the month**.
- For Drupal core the **security** release window on the **third Wednesday of the month**.
- Security releases happen between 16:00 UTC and 22:00 UTC.
- D.O. Security updates list: <https://www.drupal.org/security>
- D.O. Security updates Twitter alerts: <https://twitter.com/drupalsecurity>

## When to do the updates

- Always use a maintenance window and a **shared calendar** (with the customer) to plan the updates. For example. you should not do the updates (even if there is a sec. issue) when the site is having a high traffic campaign.
- Prefer the same dates as Drupal core security releases. For example, **the third Wednesday of each month** is a good option to plan for updates otherwise go for **the very next Monday**.
- ASAP when the security issue is of high priority.
- Do not do the updates late on the day (at least 4 hours before leaving the office) or on the last day of the week (eg Friday).
- Try to do the updates when all the related parts are active (developers, sysadmin, hosting provider, customer etc)
- Do not plan for updates then other systems (eg the Hosting Provider) is also having a maintenance window.

## Best practices

- Security updates should be done as a "**first level task**" and not as a minor boring task.
- During the update the developer(s) should always follow all the steps even if you are sure they are not needed.
- During the update the developer(s) should not be tired, doing multitasking, talking on the phone etc.
- During the update the developer(s) should not be on a hurry when doing the sec. updates.
- After the update the developer(s) should monitor the site for some time and be ready to revert/act if anything happens (eg for 1 day).
- Demand a **content freeze** during the updates (you can use the module [readonlymode](https://www.drupal.org/project/readonlymode) or the core **maintenance_mode** variable for that).
- Decide the **Maintenance windows** (date or range of dates).
- Use a **Maintenance windows calendar** (a calendar shared with the parts evolved where the site owner should mention which dates should not be an option for security updates).
- Send **Maintenance emails** before and after the update (inform the customer about the **upcoming** update, inform the customer about the update **happened**).
- Create a **technical report** about each update (git tag/commit, Drupal core, Drupal contrib versions, PHP packages versions). You can use tools like [generate_drupal_report](https://github.com/theodorosploumis/generate_drupal_report).
- Add **datetime to bash history** so each cli command has a datetime entry.
- Use a special **cli color when ssh on a Production server** (eg make it with red background).
- Allow for emergency **system rollback** from the UI (code, database, public files). This is needed in cases where an error occur after a sec. update and there is lack of communication between the sec. team and the site owner.
- First complete the sec. updates on a **full copy of the Prod site (code, db, public files, same server config)** before doing the same on Prod.
- Establish a **manual (UAT) testing** guide to allow the customer check the updates.
- Establish a **clean plan about the responsibilities**. Who is going to have each responsibility, which are the communication options (email, phone etc), which are the tasks need to be done when a problem arise etc.
- If there are **many companies or vendors evolving** be careful about any misunderstands and delays that may happen due to the number of the people evolved.
- Developers and other parts evolved should update a **shared checklist** for all the steps required.
- Save all the `drush updb` cli logs for each update on a log file for reference.

## Updating Drupal distributions (installation profiles)

> For example [open social](https://www.drupal.org/project/social), [opigno_lms](https://www.drupal.org/project/opigno_lms) etc.

- Some distributions (e.g. Open Social) already have a recommended process to run updates and sometimes there is also a UI for updates. Follow that guide instead of yours.
- Prefer to use a **strict version** of the distribution on `composer.json`.
- Let the distribution handle the 2nd level requirements (eg Drupal modules) and **don't override them on `composer.json`** unless there is a reason to do so.
- Before any update please read carefully the distribution changelog and notes.
- Check your current version of the distribution (the `composer.json` of it) with the new version you want to update to. This will allow you to inspect which packages and settings have changed on the new `composer.json`. You can use `git diff` or [GitHub compare](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/viewing-and-comparing-commits/comparing-commits). See for example the Open Social `composer.json` diff between versions `11.7.0` and `11.8.2`: [goalgorilla/open_social/compare/11.7.0...11.8.2#diff...](https://github.com/goalgorilla/open_social/compare/11.7.0...11.8.2#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34)
- If there are conflicts on updates try to delete the `composer.lock` before upadating.
- If there are conflicts on updates read the composer logs carefully and then try to fix each problem line by line.
- Command `composer why X` is your friend.
- It is a good practice to not leave your projects that depend on a Drupal distribution without updates for a long time.
- It is a good practice to get informed (e.g. through Drupal RSS or GitHub watch) about new releases of the Drupal distribution you depend to.

## Monitor site health

- Uptime monitoring (external SASS, eg [uptimerobot](https://uptimerobot.com), [New Relic](https://newrelic.com))
- Get SMS and email alerts for PHP fatal errors on Drupal

## Related guides

- [Drupal report](https://github.com/theodorosploumis/drupal-report)
- [Generate drupal report script](https://github.com/theodorosploumis/generate_drupal_report)
- [Notes: Drupal Contract](contract.md)
- [Notes: Deployment workflow for Drupal](deployment-workflow.md)
- [Notes: Testing Drupal](testing/README.md)