>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3589055. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !19 >>> <p>Follow-up to <a href="https://www.drupal.org/project/domain_theme_switch/issues/3551634">#3551634</a> (3.x rewrite for Domain 3.x compatibility).</p> <h3>Background</h3> <p>The 2.x version of this module shipped a permission named <code>domain administration theme</code> (human-readable label "Use domain admin theme") used by the now-deleted <code>ThemeSwitchNegotiator</code>:</p> <pre>public function applies(RouteMatchInterface $route_match) { if (!($domain = $this-&gt;negotiator-&gt;getActiveDomain())) { return FALSE; } $this-&gt;defaultTheme = $this-&gt;adminTheme = $this-&gt;domainThemeLookup-&gt;getDefaultTheme($domain-&gt;id()); if ($this-&gt;currentUser-&gt;hasPermission('domain administration theme')) { $this-&gt;adminTheme = $this-&gt;domainThemeLookup-&gt;getAdminTheme($domain-&gt;id()); } return TRUE; } public function determineActiveTheme(RouteMatchInterface $route_match) { return ($this-&gt;isAdminRouteUrl($route_match) === FALSE) ? $this-&gt;defaultTheme : $this-&gt;adminTheme; }</pre><p>The permission gated the application of the per-domain ADMIN theme: only users holding it saw Claro/Gin/etc. on <code>/admin/*</code> paths; everyone else saw the per-domain front-end theme even on admin pages.</p> <h3>Why the permission is gone in 3.x (and is staying gone)</h3> <p>Drupal core has been discussing for a while the deprecation of the separate admin-theme system in favour of a single unified UI (Claro/Gin convergence, the broader Starshot conversations). Nothing is formally deprecated yet, but the signal is consistent enough that the 3.x rewrite chose to align with it: the custom <code>ThemeSwitchNegotiator</code> (and the gate permission with it) was scrapped, and per-domain themes are now applied via <code>domain_config</code> overrides on <code>system.theme:default</code> / <code>system.theme:admin</code>, picked up uniformly by Drupal core's existing theme resolution.</p> <p>The 2.x gate could be reinstated as a thin <code>ThemeNegotiatorInterface</code> ordered above <code>theme.negotiator.admin_theme</code>: when the current user is on an admin route and lacks the permission, return the per-domain front-end theme; otherwise let core's admin negotiator pick the per-domain admin theme. Roughly 30-50 lines plus a resurrected <code>permissions.yml</code>. The reason <em>not</em> to do that here is the same direction-of-travel argument: re-investing in the admin/front-end theme split for the sake of a niche per-user gating feature is hard to justify when core may retire the split. If the gate turns out to matter for actual users, restoring it remains an easy follow-up issue against a future minor release; cleaning up the dead permission first does not foreclose that.</p> <p>The permission was removed (along with its <code>permissions.yml</code> and the negotiator class) in commit <a href="https://git.drupalcode.org/project/domain_theme_switch/-/commit/f1168dd">f1168dd27fcab112cb6c68781c2c88d9b3697336</a> as part of #3551634.</p> <h3>Symptom</h3> <p>Sites updating from 2.x to 3.x have role configs that still reference the deleted permission. Drupal warns on each role save / config import:</p> <blockquote><p>Les autorisations inexistantes attribu&eacute;es au r&ocirc;le "..." ont &eacute;t&eacute; supprim&eacute;es. Autorisation(s) invalide(s) : domain administration theme.</p> </blockquote> <p>Drupal cleans the active config but the staged config in <code>config/sync</code> stays out of sync until each affected role is re-saved or hand-edited.</p> <h3>Proposed fix</h3> <p>Add <code>domain_theme_switch_update_10002()</code> that revokes the obsolete permission from any role that still has it. Idempotent: no-op on sites that never had the permission or whose roles have already been cleaned.</p> <pre>function domain_theme_switch_update_10002() { $obsolete_permission = 'domain administration theme'; $cleaned_role_ids = []; foreach (Role::loadMultiple() as $role_id =&gt; $role) { if ($role-&gt;hasPermission($obsolete_permission)) { $role-&gt;revokePermission($obsolete_permission); $role-&gt;save(); $cleaned_role_ids[] = $role_id; } } if (empty($cleaned_role_ids)) { return t('No roles referenced the obsolete "@permission" permission; nothing to clean up.', [ '@permission' =&gt; $obsolete_permission, ]); } return t('Revoked the obsolete "@permission" permission from @count role(s): @roles.', [ '@permission' =&gt; $obsolete_permission, '@count' =&gt; count($cleaned_role_ids), '@roles' =&gt; implode(', ', $cleaned_role_ids), ]); }</pre><p>This is the kind of cleanup that should have shipped alongside the permission removal in #3551634; filing now as a follow-up.</p>