Apply domain path alias processing on outbound URLs with a domain option

Problem

When code sets $url->setOption('domain', 'example_com') directly (without going through DomainSourcePathProcessor), domain path aliases are not applied. Core's PathProcessorAlias (priority 300) aliases the path for the active domain, and nobody re-aliases it for the target domain.

This is because domain_path currently resolves aliases only via hook_domain_source_alter, which is fired by DomainSourcePathProcessor (priority 90) — but that processor skips processing when $options['domain'] is already set.

Solution

New outbound path processor DomainPathOutboundProcessor at priority 85 (after DomainSourcePathProcessor at 90, before DomainPathProcessor at 80):

1. Skips external URLs or paths without $options['domain']
2. Reverse-resolves the current path back to the internal system path (undoing core's active-domain aliasing)
3. Looks up the correct alias for the target domain via getAliasByPathAndDomain()

The processor is safe for double-processing: when hook_domain_source_alter has already replaced the path (domain_source flow), the reverse-resolve typically fails (returns the path unchanged), and the target-domain lookup also returns the same path. Net result: path stays unchanged.

Priority chain

Changes

• New: src/HttpKernel/DomainPathOutboundProcessor.php
• Modified: domain_path.services.yml — registered the new service at priority 85
• New: tests/src/Functional/DomainPathDomainOptionTest.php — 3 test methods covering alias resolution, fallback without alias, and non-canonical route exclusion

Depends on

#3574800 (domain module: DomainPathProcessor with the domain URL option)

Current architecture (this MR)

The problem: core's AliasPathProcessor (priority 300) runs first and aliases the path for the active domain. Then our processor at 85 has to undo that (reverse-resolve with getPathByAlias) and redo it for the target domain. This reverse-then-forward dance works but is wasteful.

@idebr proposed architecture

Key insight: by running before core's AliasPathProcessor (priority 305 > 300), you alias the path for the target domain first. Then you set $options['alias'] = TRUE, which is core's built-in mechanism to tell AliasPathProcessor "aliasing is already done, skip it" (AliasPathProcessor.php line 45). No reverse-resolve needed.

Also: hook_domain_source_alter would no longer be needed because DomainPathOutboundProcessor handles the aliasing directly — DomainPathFormHooks::domainSourceAlter() was only used to swap the alias for the target domain, which this processor now does.

Trade-offs

This approach is cleaner because:

• No wasteful reverse-resolve + re-resolve
• Uses core's own $options['alias'] skip mechanism
• Removes the hook_domain_source_alter implementation

Considerations:

• DomainSourcePathProcessor moving from 90 to 310 is a bigger change in the domain module — it needs to work correctly running before core aliasing instead of after
• Any code relying on hook_domain_source_alter to modify the alias would break
• The path passed to DomainSourcePathProcessor at 310 would be the internal path (e.g. /node/1) rather than an alias, which might actually be simpler

I'll rework the implementation to follow this approach — seems like a solid improvement.

@idebr could you validate this issue please? https://www.drupal.org/project/domain/issues/3575227

Service renamed.

Looks Domain Path 2.x will now require Domain 3.x.

Don't know what to think about that.

I'll go directly to 3.x to match domain module versioning.

Implemented your suggestion that should definitely improve performance.

Should be ready for merge.

Is it ok for you @idebr?

Looks like our latest changes have introduced some regressions.

Investigating.

@idebr ok, found the culprit, $options['language'] is not populated anymore after moving DomainSourcePathProcessor at priority 310.

The domain_source field can be translated, so it's currently totally broken.

How could we fix that?

May be we can get the current language by ourselves if not provided in $options['language'].

What do you think?