Issue #3588538: Drop domain_config_ui dependency; use domain_config override factory directly

Frank Mablyrequested to merge
issue/domain_theme_switch-3588538:3588538-symfonycomponentdependencyinjectionexceptionservicenotfoundexception-you-have into 3.x

Symptom

After upgrading from 2.1.1 to 3.0.0, sites that did not have domain_config_ui enabled hit a critical WSOD as soon as update_10001 ran:

ServiceNotFoundException: You have requested a non-existent service "domain_config_ui.manager"
   in DomainThemeSwitchConfigForm::create() (line 41)

(Reported by dbielke1986.)

Root cause

The 3.x rewrite (commit f1168df, Issue #3551634) introduced hard uses of domain_config_ui.manager:

  • src/Form/DomainThemeSwitchConfigForm.php (constructor + 3 method calls)
  • domain_theme_switch.install:19 — update_10001() calls addConfigurationsToDomain() during the 2.x → 3.x migration

But .info.yml only declared domain:domain. Drupal had no way to enforce domain_config_ui as a prerequisite, so the bug fired the moment a site without it ran the update hook.

Why the dep was avoidable in the first place

The three DomainConfigUIManager methods we used split cleanly:

  • addConfigurationsToDomain() and isConfigurationRegisteredForDomain() read/write the domain_config_ui.settings registry that powers domain_config_ui's generic any-config-form-can-be-domain-aware sprinkle. Domain Theme Switch has its own dedicated config form — the registry is irrelevant to it.
  • deleteConfigurationOverridesForDomain() internally forwards to the override factory from domain_config; that's already a domain_config primitive.

The runtime override mechanism (a tagged config.factory.override service registered by domain_config) applies whether domain_config_ui is enabled or not. So nothing in the actual theme-switching behaviour requires domain_config_ui.

What this MR does

Replaces the manager with DomainConfigFactoryOverrideInterface from domain_config:

  • Form — injects domain.config_factory_override instead of domain_config_ui.manager. "Has theme override?" becomes a check on the per-domain storage ($storage->exists('system.theme')). Saves and deletes go through getOverrideEditable() and getOverride(). The per-domain registration call goes away.
  • Install hook — update_10001() uses the same override factory to write the migrated theme config; the manual collection plumbing and the addConfigurationsToDomain() registry write are dropped.
  • Functional test — no longer enables domain_config_ui. The test now exercises the headless path (the path users without domain_config_ui actually hit).
  • info.yml — domain:domain_config_ui leaves the dependency list. domain:domain_config joins the list (it's directly used), and domain:domain stays (entity storage queries on the domain entity).
 dependencies:
   - domain:domain
+  - domain:domain_config
-  - domain:domain_config_ui

Effects on existing users

Sites that did not have domain_config_ui (the bug reporter's case): the update hook now succeeds and the form works.

Sites that have domain_config_ui enabled: still work. Their previously-registered system.theme entry in domain_config_ui.settings remains untouched; the form simply no longer maintains that registry entry on their behalf when toggling overrides. The per-domain config collection (which is what actually drives the theme switch) is the source of truth in either case.

Verification

Updated DomainThemeSwitchFormTest still covers: form rendering with/without domains, enabling and disabling overrides, updating values, multiple-domain overrides, and the rendered-theme assertion (core/themes/olivero/ appearing on the front-end after a switch). Now runs without domain_config_ui in $modules, confirming the headless code path is functional.

Merge request reports