>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3613716. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !44 >>> <h3>Problem/Motivation</h3> <p>Whatever advances a piece of work is not always the domain that work belongs to. An operator validates, from a back office domain, an order placed on the public site; cron releases a hold with no active domain at all; a queue worker mails a customer hours later. Rendering then inherits the context of the request doing the work, so the message carries the wrong links, the wrong site name and the wrong per-domain configuration.</p> <p>Switching the domain negotiation context carries most of the load: per-domain configuration overrides read the active domain from it, and so does <code>DomainPrefixPathProcessor::processOutbound()</code>, so the domain path prefix and the target domain's language prefix both follow. What it does not carry is the host. <code>UrlGenerator::generateFromRoute()</code> reads the scheme, host and port from core's <code>router.request_context</code>, and the only thing in Domain that overrides them is <code>DomainPathProcessor</code>, which returns early unless a <code>domain</code> option is set on the individual URL. Measured on a site with both prefixed and separate-host domains, switching the negotiation context alone yields a URL with the right prefix, the right language and the wrong host.</p> <p>Every module that sends something out of band ends up repeating the same save, set and restore dance, including Domain itself in <code>DomainPathProcessor::processLanguageNegotiationOutbound()</code>. With <code>DomainNegotiator::setActiveDomain()</code> and <code>setRequestDomain()</code> deprecated for removal in Domain 4.0, each copy is also a separate migration.</p> <h3>Proposed resolution</h3> <p>A new <code>domain_render_context</code> submodule with one service, <code>domain_render_context.renderer</code>:</p> <ul> <li><code>inDomain($domain, callable $callback)</code>: runs the callback as if the request had come from the given domain, restoring the previous context on return and on an exception.</li> <li><code>enter($domain)</code>: the lower-level counterpart, returning the closure that restores the previous context, for work that does not fit in one callback such as a queue worker. Safe to call more than once.</li> </ul> <p>It switches exactly two things: the domain negotiation context (per-domain configuration, path prefix, the target domain's language negotiation configuration) and the scheme, host and port of the router request context. It does not switch the theme, the interface language, the session or the current user, and it does not push a request onto the request stack. An unknown machine name is logged and the current context is kept, so a deleted domain never turns a notification into a fatal error.</p> <p>Outbound only, and documented as such: it must never be called while a page is being routed or rendered for the browser, since the negotiated domain also drives inbound path processing, routing and language negotiation for the page being served.</p> <p>Compatibility: uses only API available from Domain 3.0 through 4.x, and calls nothing deprecated for removal in 4.0.</p> <h3>Remaining tasks</h3> <ul> <li>Submodule, service and interface.</li> <li>Kernel coverage: configuration and request origin switch, path prefix follows the switch, restore on a normal return, on an exception, on nested calls, on an unknown domain, on a run that started with nothing negotiated, and an idempotent restore closure.</li> <li>README and a documentation page.</li> <li>Follow-up upstream: <code>DomainNegotiationContext::setDomain()</code> cannot take NULL, so a context that held no domain on entry (cron, the CLI) cannot be emptied again. The restore re-negotiates from the current request instead, which is what the next read would have produced anyway. A nullable signature in Domain would let the restore be exact.</li> </ul> <h3>User interface changes</h3> <p>None. Code only, no UI, no configuration.</p> <h3>API changes</h3> <p>New submodule and a new service. Nothing existing changes.</p>