>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3588108. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !33 >>> <h3>Problem/Motivation</h3> <p>Drupal core's three menu-related plugin managers (<code>Drupal\Core\Menu\LocalTaskManager</code>, <code>Drupal\Core\Menu\LocalActionManager</code>, <code>Drupal\Core\Menu\ContextualLinkManager</code>) key their plugin definition cache on the current language only:</p> <pre>$this-&gt;setCacheBackend($cache, 'local_task_plugins:' . $language_manager-&gt;getCurrentLanguage()-&gt;getId(), ['local_task']);</pre><p>Derivers running through these managers can read overridable configuration (e.g. <code>Drupal\block\Plugin\Derivative\ThemeLocalTask</code> reads <code>system.theme.default</code>), so their output varies per active domain &mdash; but the cached result does not, and the first domain to populate the cache freezes the answer for everyone else. Symptom proven on the block administration page (<code>/admin/structure/block</code>): the "default theme" tab title is identical across domains even when each domain has a different default theme override registered through domain_config_ui.</p> <p>The <a href="https://www.drupal.org/i/3588057">parent issue #3588057</a> (in the <code>domain</code> project) currently lands the fix as a class swap in <code>DomainServiceProvider::alter()</code> on the always-loaded base module. This issue is the alternative location: a dedicated experimental submodule in <code>domain_extras</code> so the fix is opt-in by module install.</p> <h3>Why an extras submodule</h3> <ul> <li><strong>Cache fragmentation is opt-in.</strong> Every site running <code>domain</code> binds an active domain on every request. With the swap always on, the local task plugin definition cache fragments per domain regardless of whether anyone registered an overridable config &mdash; small footprint, but a cost imposed on users who get nothing for it.</li> <li><strong>Container rebuild semantics.</strong> Service-provider <code>alter()</code> runs at container compile time. Toggling the fix would mean invalidating the cached container, which is heavier than the entity-type-definition clear we used in <code>domain_config_ui_extras</code>. Module install/uninstall does container rebuilds automatically and idiomatically &mdash; no additional subscriber needed.</li> <li><strong>Discoverability.</strong> "Domain Menu Extras (experimental)" on the modules list is more visible than a buried boolean flag.</li> <li><strong>Consistency with the precedent set by <a href="https://www.drupal.org/i/3588091">#3588091</a></strong> (<code>domain_config_ui_extras</code>): layered, opt-in fixes for issues that go beyond the base module's contract live in their own <code>_extras</code> submodule.</li> <li><strong>Group related fixes.</strong> The same fix shape applies to all three Menu/* managers (LocalTask, LocalAction, ContextualLink). One submodule colocates them.</li> </ul> <h3>Proposed resolution</h3> <p>New submodule <code>domain_menu_extras</code>:</p> <ul> <li><code>DomainAwareLocalTaskManager extends LocalTaskManager</code> &mdash; re-binds the cache backend in its constructor with key <code>local_task_plugins:LANGCODE:DOMAIN_ID</code> (falling back to <code>und</code> before negotiation). This is the same code already proposed on <a href="https://www.drupal.org/i/3588057">#3588057</a>, just relocated.</li> <li>Same shape for <code>LocalActionManager</code> and <code>ContextualLinkManager</code>: <code>DomainAwareLocalActionManager</code> and <code>DomainAwareContextualLinkManager</code>.</li> <li>A small <code>DomainMenuExtrasServiceProvider</code> that, in <code>alter()</code>, calls <code>setClass()</code> + <code>addArgument('@domain.negotiation_context')</code> for the three core service definitions.</li> <li>Module info: <code>lifecycle: experimental</code>, <code>core_version_requirement: ^10.2 || ^11</code>, depends on <code>domain:domain</code>.</li> </ul> <p>Per-request overhead is one extra string concatenation per manager instantiation; cache fragmentation is bounded by the number of domains actually visited.</p> <h3>Steps to reproduce</h3> <ol> <li>Multi-domain site with <code>system.theme</code> registered as overridable through <code>domain_config_ui</code> for at least two domains, with different default themes per domain.</li> <li>Visit <code>/admin/structure/block</code> on each domain &mdash; the "default theme" tab title is the same on both.</li> <li>Enable this submodule, <code>drush cr</code>.</li> <li>The tab title reflects each domain's default theme.</li> </ol> <h3>Module info</h3> <ul> <li>name: Domain Menu Extras</li> <li>package: Domain</li> <li>lifecycle: experimental</li> <li>core_version_requirement: ^10.2 || ^11</li> <li>dependencies: domain:domain</li> </ul> <h3>Related</h3> <ul> <li><a href="https://www.drupal.org/i/3588057">#3588057</a> &mdash; parallel proposal landing the same fix in the <code>domain</code> base module. Goal of the present issue is to provide a side-by-side comparison so we can pick one location.</li> <li><a href="https://www.drupal.org/i/3588091">#3588091</a> &mdash; established the <code>_extras</code> submodule pattern in <code>domain_extras</code>.</li> </ul>