<h3 id="summary-problem-motivation">Problem/Motivation</h3> When a configuration language lock is active, config_language_lock queues a batch after a module or theme is installed to rewrite affected configuration items to the locked language. The batch callbacks are registered with Drupal’s container-resolved callback syntax: ``` ConfigLanguageLockBatch::class . ':batchUpdateConfigChunk' ConfigLanguageLockBatch::class . ':batchFinished' ``` Both target non-static methods of a container-managed service with constructor-injected dependencies. Drupal core’s web batch runner resolves this callback form through its callable resolver. Drush 13 processes batches with direct PHP callable validation and call_user_func_array(), so it cannot instantiate this service-backed callback. As a result, installing a module through Drush fails whenever the configuration language lock is enabled. For example: drush en masquerade fails with: ``` TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function "Drupal\config_language_lock\ConfigLanguageLockBatch:batchUpdateConfigChunk" not found or invalid function name ``` This also affects batches queued after theme installation and after changing the site default language while follow_site_default is enabled. <h4 id="summary-steps-reproduce">Steps to reproduce</h4> 1. Install Drupal 11 with Drush 13. 2. Enable config_language_lock. 3. Configure a valid locked configuration language, for example: locked_langcode: en follow_site_default: false 4. Install a module through Drush: drush en masquerade 5. Observe that Drush starts processing the batch queued by ConfigLanguageLockHooks::modulesInstalled() and terminates with the invalid callback error. <h3 id="summary-proposed-resolution">Proposed resolution</h3> Use standard PHP callable arrays with static callback wrappers for batch operations and completion callbacks. Change the callback registration from: ``` $batch_builder->addOperation(self::class . ':batchUpdateConfigChunk', [$chunk]); $batch_builder->setFinishCallback(self::class . ':batchFinished'); ``` to: ``` $batch_builder->addOperation([self::class, 'batchUpdateConfigChunk'], [$chunk]); $batch_builder->setFinishCallback([self::class, 'batchFinished']); ``` Make the public batch callbacks static, then delegate to protected instance methods on the existing container-managed service: ``` public static function batchUpdateConfigChunk(array $names, array|\ArrayAccess &$context): void { \Drupal::service(self::class)->doBatchUpdateConfigChunk($names, $context); } public static function batchFinished(bool $success, array $results): void { \Drupal::service(self::class)->doBatchFinished($success, $results); } ``` This preserves existing dependency injection and business logic while making the callback valid for both: - Drupal core’s web batch runner. - Drush 13’s batch runner. <h3 id="summary-remaining-tasks">Remaining tasks</h3> - Review and commit the proposed patch. - Add regression coverage for running the module-install batch through Drush, if the module test setup supports Drush integration tests. - Test module installation, theme installation, and the follow_site_default language-change workflow through both the web UI and Drush. <h3 id="summary-ui-changes">User interface changes</h3> None. <h3 id="summary-introduced-terminology">Introduced terminology</h3> None. <h3 id="summary-api-changes">API changes</h3> ConfigLanguageLockBatch::batchUpdateConfigChunk() and ConfigLanguageLockBatch::batchFinished() become static public callback wrappers. The underlying implementation moves to protected instance methods so it can continue using the existing injected services. <h3 id="summary-data-model-changes">Data model changes</h3> None. <h3 id="summary-release-notes">Release notes snippet</h3> Fixed configuration language lock batches failing during module and theme installation through Drush 13. <h3>AI assistance disclosure</h3> Initial investigation and the proposed patch were developed with assistance from an AI language model. The reported behavior, affected code paths, callback compatibility, and patch applicability were verified manually in a local Drupal 11 / Drush 13 environment.