>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3588707. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !17 >>> <h3>Problem</h3> <p>In 2.x, <code>domain_theme_switch.info.yml</code> declared only <code>domain:domain</code> as a dependency. The 3.x rewrite (#3551634) and the follow-up service fix (#3588538) introduced a hard dependency on the <code>domain_config</code> module, now declared in <code>info.yml</code>:</p> <pre>dependencies: - domain:domain - domain:domain_config</pre><p>For sites upgrading from 2.x to 3.x, <code>domain_config</code> is typically not enabled, and the new code path uses <code>domain.config_factory_override</code> (provided by <code>domain_config</code>) directly &mdash; both in the configuration form and in <code>domain_theme_switch_update_10001()</code>.</p> <h3>What actually happens on upgrade</h3> <p><code>composer update</code> only changes files on disk; it does not touch the database. <code>core.extension</code> still lists <code>domain_theme_switch</code> as enabled, and Drupal is lenient about already-enabled modules whose <code>info.yml</code> deps become unmet: <code>ModuleHandler::loadAll()</code> still loads them (you only see a warning on the modules report).</p> <p>So the site keeps booting after the composer update. The crash only happens when code touches the missing service:</p> <ul> <li>An admin visits <code>/admin/config/domain/themes</code> &rarr; <code>ServiceNotFoundException</code> on <code>domain.config_factory_override</code>.</li> <li>The site builder runs <code>drush updb</code> &rarr; <code>update_10001</code> requests the same service and dies.</li> </ul> <h3>Steps to reproduce</h3> <ol> <li>Install Domain 2.x and Domain Theme Switch 2.x; configure a per-domain theme.</li> <li>Upgrade Domain to 3.x and Domain Theme Switch to 3.x via Composer, without manually enabling <code>domain_config</code>.</li> <li>Run <code>drush updb</code> (or visit <code>/update.php</code>).</li> </ol> <p>Result: <code>ServiceNotFoundException</code> from <code>update_10001</code> aborts the database update.</p> <h3>Proposed resolution</h3> <p>Keep the <code>domain_config</code> entry in <code>info.yml</code> &mdash; it is a real runtime dependency and removing it would lie to Composer, static analysis and fresh installs. Instead, add <code>hook_requirements('update')</code> in <code>domain_theme_switch.install</code> to gate the update flow with a clear, actionable message.</p> <p>This relies on the standard ordering used by <code>drush updb</code> / <code>update.php</code>:</p> <ol> <li>Bootstrap Drupal (succeeds &mdash; already-enabled modules with unmet info.yml deps still load).</li> <li>Invoke <code>hook_requirements('update')</code> on every enabled module. Any <code>REQUIREMENT_ERROR</code> aborts before any <code>hook_update_N</code> runs.</li> <li>Run pending <code>hook_update_N</code> hooks.</li> <li>Run <code>hook_post_update_N</code> hooks.</li> </ol> <p>So the gate fires before <code>update_10001</code> ever touches <code>domain.config_factory_override</code>:</p> <pre>function domain_theme_switch_requirements($phase): array { $requirements = []; if ($phase === 'update' &amp;&amp; !Drupal::moduleHandler()-&gt;moduleExists('domain_config')) { $requirements['domain_theme_switch_domain_config'] = [ 'title' =&gt; t('Domain Theme Switch'), 'description' =&gt; t('Domain Theme Switch 3.x requires the Domain Configuration module. Enable it (drush en domain_config) before running database updates.'), 'severity' =&gt; REQUIREMENT_ERROR, ]; } return $requirements; }</pre><p>Recovery for upgrading users becomes:</p> <pre>composer update drupal/domain drupal/domain_theme_switch drush updb # blocked with a clear, actionable message drush en domain_config drush updb # passes requirements; update_10001 migrates the config</pre><h3>Caveat</h3> <p>The update-phase gate does not prevent an admin who visits <code>/admin/config/domain/themes</code> between <code>composer update</code> and <code>drush updb</code> from hitting the same <code>ServiceNotFoundException</code> on the form. Adding a <code>hook_requirements('runtime')</code> with <code>REQUIREMENT_WARNING</code> would at least surface the issue on the status report, though it cannot actually block the form. In practice the update-time gate is what users hit first, since the standard upgrade workflow is <code>composer update</code> &rarr; <code>drush updb</code>.</p> <p>A short note should also be added to the README and the 3.0.x release notes pointing out the new requirement.</p> <h3>Related issues</h3> <ul> <li>#3551634 &mdash; Create new 3.x version compatible with Domain 3.x</li> <li>#3588538 &mdash; ServiceNotFoundException: domain_config_ui.manager (where the dependency was added)</li> </ul>