Drupal 10/11: Handling Updates with Drush Without Blocking Deployment

Share on

Introduction

When deploying a Drupal update, it is common to use the following commands:

set -e
drush updb -y
drush cim -y
drush cr

However, some updates require services that are not yet available, which can cause SQL errors and block the deployment. In this article, discover how to adapt your script to avoid these blockages, with a concrete example: Drupal update system_update_11201 (adding the "alias" column to the "router" table).

Note the "drush deploy" also do no cr before updb.

The Problem: A Blocking SQL Error

When running "drush cr" before "drush updb -y", you may encounter the following error:

[error] Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'alias' in 'field list': INSERT INTO "router" ("name", "route", "alias") VALUES (:db_insert_placeholder_0, ...

This error is normal: the "alias" column does not exist yet because it is created by update system_update_11201. If the script stops at this point, the deployment is blocked.

The Solution: Allow the First "drush cr" to Fail

To work around this issue, modify your deployment script as follows:

#!/bin/bash
# Disable error stopping for the first "drush cr"
set +e
drush cr
set -e
# Run the Drush update commands
drush updb -y
drush cim -y
drush cr

• "set +e": Disables script termination on error for the next command.
• "drush cr": Attempts to clear the cache but may fail without blocking the script.
• "set -e": Re-enables error stopping for subsequent commands.

Why This Approach?

• Flexibility: The script continues even if the first "drush cr" fails.
• Robustness: Updates ("updb") and configuration imports ("cim") execute normally.
• Clean Finalization: The last "drush cr" ensures the cache is cleared after the update.

Use Case: core system_update_11201

Update system_update_11201 adds the "alias" column to the "router" table. Without this adaptation, the deployment would systematically fail before even applying the update.

DevOps Best Practices for Drupal

1. Test Locally: Simulate the scenario before deploying to production.
2. Monitor Logs: Use "drush ws" to check for errors.
3. Automate: Integrate this script into your CI/CD pipelines (GitLab CI, GitHub Actions, etc.).

Conclusion

By adapting your deployment script, you avoid blockages related to dependencies between services and SQL updates. This tip is particularly useful for critical updates like update system_update_11201.