🔐 Drupal 11.2.5 Update: Composer Path Configuration Is No Longer Flexible—Here’s What You Need to Know

By admin, 16 September, 2025

With the release of Drupal 11.2.5, a subtle but important change has landed that affects how sites interact with Composer and rsync via the Package Manager. If you’ve been relying on configuration to define executable paths, it’s time to refactor.

🚫 What Changed?

For security reasons, Drupal core has removed the ability to configure paths to Composer and rsync via configuration files. This means:

You can no longer set these paths in package_manager.settings.
Package Manager now uses a strict lookup order.
Any outdated config will trigger warnings in the status report.

✅ New Behavior: Composer Lookup Order

Package Manager will now search for Composer in the following order:

Locally installed (preferred):
```
vendor/composer/composer/bin/composer
```

Explicitly set in settings.php:

$settings['package_manager_composer_path'] = '/custom/path/to/composer';

Web server’s PATH:
If neither of the above is found, it defaults to the system-wide Composer.

🔒 This behavior is hardcoded and cannot be overridden via config.

🧪 Example: Adding Composer to Your Project

To ensure compatibility and avoid status report warnings, add Composer as a dependency:

composer config allow-plugins.drupal/core-vendor-hardening true
composer config extra.drupal-core-vendor-hardening --merge --json '{"composer/composer": false}'
composer require "drupal/core-vendor-hardening:^11.2.4" "composer/composer:^2.7"

This ensures Package Manager uses the correct version and location of Composer.

🔄 rsync Path Handling

Package Manager now checks for rsync in:

Explicit setting in settings.php:

$settings['package_manager_rsync_path'] = '/usr/bin/rsync';

Web server’s PATH (preferred):
If rsync is globally available, no action is needed.

🧹 Clean-Up: Remove Dead Config

Once paths are correctly set, clean up the old config to silence warnings:

vendor/bin/drush config:delete package_manager.settings executables

This removes the deprecated executables config entry and ensures a clean status report.

👥 Who’s Affected?

Site builders managing deployments
Module developers relying on Package Manager
Distribution maintainers customizing Composer/rsync behavior

🧩 Final Thoughts

This change may seem minor, but it’s part of a broader effort to harden Drupal’s security posture. By enforcing executable paths through code and environment, Drupal reduces the risk of misconfiguration or malicious overrides.

If you’re maintaining custom modules or CI/CD pipelines, now’s the time to audit your setup. Need help adapting your deployment scripts or writing fallback logic for Composer detection? Drop a comment or reach out—I’d be happy to share some reusable snippets.