Motivation
A requirement for experience builder outlined in #3484255: Support adding additional routes for view modes other than 'full' is to have alternative canonical routes, where the routes are tied to configured view modes. The view modes would have configured paths, just like entities have a canonical path.
This issue exists to add a system for custom paths for alternate canonical routes.
View mode variants will be added in #3484255: Support adding additional routes for view modes other than 'full'.
Contrib impact
- Pathauto would be able to hook in with their own patterns.
- Subpathauto would be able to register patterns in a performant way. E.g [entity:title]/customPath. (Computation of "subpaths" can happen beforehand, instead of at runtime)
I suggest this issue as a predecessor to #3484255: Support adding additional routes for view modes other than 'full', since I dont think it makes sense to tie internals of Path/PathAlias, especialy PathAlias
entity, PathItem
, PathFieldItemList
, and PathWidget
, with concepts like Entity View Modes. Especially since there should be contrib hookability. And be able to integrate with Core concepts like Entity Form Modes in the future.
Doing all this before #3484255: Support adding additional routes for view modes other than 'full' allows its view mode integration to stay very small. I've created a MR in that issue that stacks on the MR here @ !REPLACE.
What this will not do?
- Add user accessible variants. See #3484255: Support adding additional routes for view modes other than 'full' for the first first-party variants.
- Add a subpathauto-alike system where variants get paths like
/node/1
+/node/1/alternative
=/mycontent
+/mycontent/alternative
.
Proposed resolution
Implement appropriate events to allow core and contrib to specify variants, and variant and internal paths.
Remaining tasks
Architectural and technical review
Add coverage for new systems
Test passing
User interface changes
A path fieldset is displayed PER variant.
Introduced terminology
- Path variants
API changes
- API surface additions just for variants.
- New events dispatched
- Existing
path_alias.repository
and its interface had a change to\Drupal\path_alias\AliasRepository::lookupBySystemPath
method signature to allow optional variant lookups.
Data model changes
- Database schema changed: Introduces a `variant` field (database column) to PathAlias. All existing pathalias have a NULL value, which equates to the "default" variant.
- No config schema changes.