HostEntityUrlPropSource should be able to support absolute or relative URLs, URL options

Thanks for creating this!

Note: only if the path_processing URL generator option is set to FALSE would an actual permalink be bgenerated.

This needs to be assessed for being a stable blocker or not. Because right now, this would store the following:

{"sourceType": "host-entity-url"}

But once this MR lands, that would change to something like

{"sourceType": "host-entity-url", "rel": "canonical", "options": {"absolute": true}}

This would be a BC break and need an update path.

Unless of course we say that that is the default. But if we make this the default, then for type: string, format: uri-reference, we'd need to explicitly store

{"sourceType": "host-entity-url", "rel": "canonical", "options": {"absolute": false}}

or at least

{"sourceType": "host-entity-url", "options": {"absolute": false}}

(stored prop sources should be possible to evaluate without knowing the target prop shape — because \Drupal\canvas\PropSource\PropSourceBase::evaluate() does not receive that information)

Do we want to allow the generated URL to be relative, instead of always absolute? I'm not entirely sure it matters, but it's worth considering.

This matters a great deal.

Because all absolute URLs vary by the url.site cache context, which undermines the cacheability.

→ for type: string, format: uri-reference, only HostEntityUrlPropSource with relative URLs should be suggested, to minimize the occurrence of avoidably reduced cacheability (related: #4)

P.S.: #3554184: Bubble cacheability of resolved props values and access results + `PropSourceBase::evaluate()` does not return cacheability at all will need to fix the bubbling of cacheability of HostEntityUrlPropSource::evaluate(), too.

Postponing this until we get clarity at #3555413-10: Allow linking to referenced entities: add `url` property to `EntityReferenceItem::propertyDefinitions()`.

Unpostponing per #3555413-15: Allow linking to referenced entities: add `url` property to `EntityReferenceItem::propertyDefinitions()` 👍

This is:

1. AFAICT dangerously open-ended (from a maintainability POV)
2. does not yet have the appropriate settings-dependent labels
3. does not yet have any tests proving any of this works — \Drupal\Tests\canvas\Kernel\PropSourceTest::testHostEntityUrlPropSource() needs to be expanded significantly
4. and most crucially, does not yet update \Drupal\canvas\ShapeMatcher\PropSourceSuggester::matchHostEntityUrlPropSources()'s
   

       $matches = [];
       // @todo Offer `canonical` vs `edit-form` vs … (and check whether the given entity type actually contains such a link template) in https://www.drupal.org/i/3551455.
       // @todo Return either relative (`uri-reference`) or absolute (`uri`) suggestions in https://www.drupal.org/i/3551455.
       $matches[] = new HostEntityUrlPropSource();
       return $matches;
   

   👆 I'd expect that to return sensible new choices, and for it to then also appear in the UI :)

I think the "absolute or relative URLs" part of this issue should be stable blocking per #4, since that affects shape matching to uri vs uri-reference props. I think supporting other options and link templates can be a post-stable follow-up unless it's trivial to include here as part of solving for the absolute option.

Thanks, will review tomorrow!

On the right track, but some things were still missing:

1. Tests were literally failing due to PHP errors… 🙈
2. it was not yet updating \Drupal\canvas\ShapeMatcher\PropSourceSuggester::matchHostEntityUrlPropSources(), so nobody would EVER have gotten to use relative URLs 😅
3. test coverage for the JSON representation
4. … which would've caught the BC break I was alluding to in #4
5. still exposing core's \Drupal\Core\Url's API as-is, which is risky for the 3 reasons outlined on the MR

I've pushed commits to propose how I would like to see #2 + #4 + #5 fixed. Your call on what you do with them.

It's worth mentioning that Canvas has also already adopted the just-in-time update pattern; consider what happens in […]

This is inaccurate, for 2 reasons:

1. Component config entities do NOT contain user data. They're only used for internal tracking purposes. So different data integrity and update path considerations apply.
2. The code you reference does not update-and-overwrite Component config entities, it instead chooses to update-and-append. See \Drupal\canvas\Entity\VersionedConfigEntityBase, introduced in #3523841: Versioned Component config entities (SDC, JS: prop_field_definitions, block: default_setting, all: slots for fallback) + component instances refer to versions ⇒ less data to store per XB field row. So, no data is lost: old data is kept as-is, unchanged, because existing component instances would be referencing old Component versions, so we still need that metadata too.

There's 3 actual test failures left I'm afraid 😓

Other than that: looks fantastic! Just nits 🤓

Lint failures need to be fixed, but other than that this is good to go, so approved!

Thanks! Here's the end result in action:

(Until #3555068: Linking a `HostEntityUrlPropSource` to populate a `type: string, format: uri|uri-reference` in a `ContentTemplate` has no effect is fixed, it won't work quite right though. But that is a problem that was not introduced here.)