Update

An update is a newer release of Drupal core, a contributed module or a theme that you install on an existing site. In Drupal 11 an update has two parts: you replace the code with Composer and then you run the database updates that the new code ships. Skipping the second part leaves the site half updated.

How updating works in Drupal 11

Find out what is outdated. The core Update Status module checks for new releases during cron runs. Its Available updates report is at /admin/reports/updates, and its settings page lets you check daily or weekly and send email when a new release appears, either for all newer versions or for security updates only. On the command line, Drupal.org's guide uses composer outdated "drupal/*".

Install the code. For core, the guide runs composer update "drupal/core-*" --with-all-dependencies. Drupal.org has a separate Composer guide for modules and themes.

Run the database updates. Open /update.php or run drush updatedb. drush updatedb:status lists what is pending. The access check for update.php asks for the permission "Administer software updates", unless update_free_access is set in settings.php. Drush enables maintenance mode while updatedb runs and clears caches when it finishes, unless you pass --no-cache-clear. The code behind these updates is described in Update API.

Keep configuration in sync. If the site uses configuration management, export it after the update with drush config:export and commit it. Drupal.org warns that uncommitted configuration is reverted by the next import.

Example

A site on Drupal 11.4 sees a new patch release in the Available updates report. A developer backs up the database, runs the Composer command on a copy of the site, runs drush updatedb and drush cache:rebuild, exports configuration, and rechecks the Status report. The same commit is then deployed with composer install on the staging site and the live server, and the database updates run there too.

Common mistakes

• Updating the live site first. Drupal.org's deployment guide has you update and confirm everything on a local copy, then repeat the steps on the server.
• Running composer update on the server. It fetches the latest versions that match composer.json, which may be newer than the ones you tested. Drupal.org's deployment guide offers the alternative: move the tested composer.lock to the server and run composer install.
• Deleting a module's files before uninstalling it. Drupal.org says to uninstall on the server first, then remove the package with Composer.
• Leaving update_free_access on. It lets anyone run update.php, and the Status report flags it as an error.

For marketing and content teams

Updates are the routine that keeps the site secure and working. The database step puts the site in maintenance mode, whether it runs through Drush or update.php, so ask when updates are scheduled and whether a security release is out. After a release, check the key pages while logged out; the core update guide ends with the same test.

Sources

• Drupal.org: Updating Drupal core via Composer
• Drupal.org: Deploying a Drupal update
• Drupal change record: authorize.php, the FileTransfer and Updater systems are deprecated
• Composer: Basic usage, installing and updating dependencies
• Drush updatedb command
• Drush updatedb:status command
• Automatic Updates project page
• Drupal core 11.4.10: UpdateHooks, the Update Status help
• Drupal core 11.4.10: UpdateSettingsForm
• Drupal core 11.4.10: SystemRequirementsHooks, Database updates check
• Drupal core 11.4.10: DbUpdateController
• Drupal core 11.4.10: DbUpdateAccessCheck