>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3618169. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !24 >>> <h3>Problem/Motivation</h3> <p>Per-domain themes are stored as overrides of core's <code>system.theme</code> in the configuration collection managed by Domain Configuration. Since <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/domain/issues/3587744" title="Status: Closed (fixed)">#3587744: domain_config: Make DomainConfigOverrideEditable::save() write a sparse, cast-aware diff against base</a></span> that module stores only the keys whose values differ from the base configuration, and since <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/domain/issues/3593636" title="Status: Closed (fixed)">#3593636: Empty domain config overrides are saved as {} instead of deleted, causing perpetual drush cim/cex drift</a></span> an override whose diff is empty is deleted rather than written.</p> <p>So enabling the override for a domain and choosing the theme the site already uses stores nothing at all. The choice looks accepted, the form even shows it on reload while the values still match, and then somebody changes the site theme and that domain follows along, because there was never an override to hold it back. An explicit decision is lost with no trace that it was ever made.</p> <p>This is not hypothetical for anyone tracking the Domain 3.1.0 alphas, and it becomes the default situation once 3.1.0 is released, since this module requires <code>drupal/domain: ^3.0</code> and a normal composer update will pick it up.</p> <h4>Steps to reproduce</h4> <p>The site theme is stark. On the module's configuration form, enable the theme override for a domain and choose stark for it. Change the site theme to olivero. That domain now serves olivero rather than the stark it was explicitly given.</p> <p>Confirmed with a functional test that saves the override, asserts the storage row, changes the site theme and then reads the theme the domain actually serves.</p> <p>Five methods in <code>DomainThemeSwitchFormTest</code> already fail for this reason against a Domain checkout containing those two changes: the ones that submit values matching the baseline. The ones that submit a different theme pass. They should all go green again with the fix below, so the existing suite is what verifies it.</p> <h3>Proposed resolution</h3> <p>Declare the two keys this module owns as pinned, using the mechanism added for exactly this in <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/domain/issues/3618091" title="Status: Closed (fixed)">#3618091: Allow a config key to stay overridden when its value equals the base configuration</a></span>:</p> <ul> <li>Implement <code>hook_domain_config_pinned_keys_alter()</code> and add <code>default</code> and <code>admin</code> under <code>system.theme</code>. A pinned key is written to the override row whenever the object is saved for a domain, whether or not its value differs from the base, so an explicit theme choice is stored and survives a later change to the site theme.</li> <li>Raise <code>drupal/domain</code> in <code>composer.json</code> from <code>^3.0</code> to the release that carries <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/domain/issues/3618091" title="Status: Closed (fixed)">#3618091: Allow a config key to stay overridden when its value equals the base configuration</a></span>, since the hook does not exist before it.</li> </ul> <p>Declaring the keys is preferred over having the form ask for them case by case: the pin then applies to every writer, including a per-domain save of the Appearance form through Domain Configuration UI, which would otherwise drop it again. Domain Configuration UI is deliberately left able to edit <code>system.theme</code> per domain; excluding it would take a core configuration form away from sites that prefer that route.</p> <h3>Remaining tasks</h3> <p>Blocked until Domain releases a version containing <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/domain/issues/3618091" title="Status: Closed (fixed)">#3618091: Allow a config key to stay overridden when its value equals the base configuration</a></span>, because the composer constraint cannot name it before then.</p> <p>Check the five failing methods in <code>DomainThemeSwitchFormTest</code> go green, and add coverage that a theme equal to the site theme is still stored.</p> <p>A note in README.md about what the module stores and where.</p> <h3>User interface changes</h3> <p>None.</p> <h3>API changes</h3> <p>None.</p> <h3>Data model changes</h3> <p>None for this module. Overrides it writes gain the two pinned keys, which are ordinary override rows and round-trip through configuration sync normally.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to investigate the behavior on the Domain side. I reviewed the work before posting it; there is no merge request on this issue yet.)</p>