[META] Content templates UI for 1.0: only nodes, no exposed slots, no replacement for the view mode/display UI

This how issue is about enabling the UI. There has already been a lot of work to make the content template on the back-end. Although there are backend issues they are in support of the UI

Wanted to make a clarification here based on call between myself, @balintbrews, @hooroomoo and fmazeikis.

Current ContentTemplates require at least 1 dynamic prop. This makes sense but this requirement would force use to do issues in certain order and require larger issues. Since all of this work is on 1.x which does not have a release we deemed to ok if in the first few issues Content Templates don't actually require dynamic props and don't have a way to set them.

The requirement will be removed in #3541021: Refactor `ApiLayoutController` to support `ContentTemplate`s which is the first major back-end issue. It will be added back near the end in #3541054: Require `ContentTemplate`s to have at least one `dynamic` or `host-entity-url` prop source the actually requirement is 1 schema file change a little test coverage. Details in the related issues

#3510896: Add a new internal HTTP API for candidate `DynamicPropSource`s to enable a `ContentTemplate` UI is in 🥳 The test coverage for that revealed one bug in shape matching, which isn't a hard blocker, but needs to be fixed at some point. So created a new Non-hard-blocking bugs identified along the way — likely needs product manager decisions and triage section.

#3502887: Prepare for avoiding full page reloads: move entity type and ID from base path and into routing parameters is unblocked because #3529836: Enable starting with an empty XB UI (so without first having to create an entity with a component tree) landed! (Which means that one was missing, so added it 😇)

I doubt that we'd be okay with only supporting populating SDC-sourced component instances with structured data — we of course also want to be able to do that for code components. Which means that we have to do #3503038. See #3503038-16: Enable candidate `DynamicPropSource` suggestions for code components: refactor `GeneratedFieldExplicitInputUxComponentSourceBase` and `FieldForComponentSuggester` to need only SDC's ComponentMetadata, not SDC plugin instances for details.

We've got kind of a meta sprawl going on here 😅🙈 i.e.: what is the difference in intent/scope between:

• this issue
• vs #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model
• vs #3511366: [META] Introduce a `ContentTypeTemplate` config entity + related infrastructure

So together with @f.mazeikis and @thoward216, clarifying the scope of this meta! 🎉

• Per @lauriii months ago, we won't be building exposed slots until after 1.0.
• Per @lauriii and @effulgentsia, the ContentTemplates scope for 1.0 is limited to only Node entities — since https://git.drupalcode.org/project/experience_builder/-/commit/843e7b0b1..., because #3498525: [later phase] [META] Allow XB to be used on any content entity type (bundle), as long as it has certain entity type characteristics will happen after 1.0.
• no XB-native view mode creation UI

Per @hooroomoo 😊

Added #3543188: `ContentTemplate`'s `status` should determine if it is active to the list, this will allow adding new Content Templates through the UI and have them not take effect until they are published. It is can be worked on now

Per #3517885: Milestone 1.0.0: Production Sites this is a requirement for an XB 1.0.0 stable release, so tagging it as such.

Added #3543834: Refactor (or attempt to) all or most `ApiLayoutController*Test` classes to also test `ContentTemplate` entities

#3543188: `ContentTemplate`'s `status` should determine if it is active landed.

#3541021: Refactor `ApiLayoutController` to support `ContentTemplate`s is in.

#3541006: Create HTTP Endpoint for Content Template Preview Entities is in.

Added #3544865: `CanvasUiAccessCheck` should grant access if the user has access to content templates or code components to the IS.

#3541015: Create HTTP Endpoint for View modes/content templates is in.

And #3541006: Create HTTP Endpoint for Content Template Preview Entities no longer needs a follow-up! 🥳 Yay more green.

Not every stable blocker needs to block an RC, but this one does.

#3544865: `CanvasUiAccessCheck` should grant access if the user has access to content templates or code components landed.

#3543834: Refactor (or attempt to) all or most `ApiLayoutController*Test` classes to also test `ContentTemplate` entities landed.

#3502887: Prepare for avoiding full page reloads: move entity type and ID from base path and into routing parameters landed.

#3541027: Create new Templates menu landed, but #3545855: Followup for #3541027: UX and styling improvements for Templates menu and sidebar components was descoped from it, so adding that to the list.

#3513590: `ComponentSourceInterface::inputToClientModel()` needs to support passing a host entity is in, unblocking #3541057: Render `DynamicPropSource`s in `ApiLayoutController` for `ContentTemplate`s using the provided preview entity 👍

See my comment at #3541034-4: Render component instance form for `ContentTemplate` and support updating static props — I think that will need back-end work too, so this plan is AFAICT incomplete.

Moved #3541054: Require `ContentTemplate`s to have at least one `dynamic` or `host-entity-url` prop source to the bottom, because it's blocked on pretty much everything else happening.

Added #3546260: `ApiLayoutController::getLabel()` should return preview entity label for content templates for the BE.

Added #3546119: Templates menu must be visible for users with the `administer content templates` permission for the FE.

#3546260: `ApiLayoutController::getLabel()` should return preview entity label for content templates is in.

Added #3546996: Component instances populated by linked `DynamicPropSource`s, but inaccessible entity/field: fall back to `NULL` for these values, triggering fallback rendering to BE issues — kudos @tedbow for thinking of this! 🙏

#3503038: Enable candidate `DynamicPropSource` suggestions for code components: refactor `GeneratedFieldExplicitInputUxComponentSourceBase` and `FieldForComponentSuggester` to need only SDC's ComponentMetadata, not SDC plugin instances landed.

New:

• FE: #3548395: Linker does not appear for certain field widgets
• Shape matching (previously known, now just more important): #3541361: Find optional field instance matches for `type: object` props (images + videos), including for optional fields on bundleless entity types (e.g. `User`'s `user_picture`)

Fixed:

• #3548292: Find required field instance matches for image (`json-schema-definitions://canvas.module/image`) and video prop shapes

#3548395: Linker does not appear for certain field widgets landed, but led to the discovery of a new bug: #3548664: Some Linker choices have no effect.

#3548295: `type: string` shape matching: find `Node`'s `uid` ("Author") field instance `type: string` also landed.

Added and fixed #3548686: Allow mapping "List (integer)" field type to `type: integer` and "List (float)" to `type: float`.

BE: #3541057: Render `DynamicPropSource`s in `ApiLayoutController` for `ContentTemplate`s using the provided preview entity is fixed. But a seemingly related, but actually pre-existing BE bug surfaced: #3548165: Components in `ContentTemplate`s and `PageRegion`s are not always rendered in correct order.

#3548664 was fixed, but surfaced #3548761: Can't link (pick a DynamicPropSource) to populate an optional explicit input if that DynamicPropSource evaluates to `NULL` (typically: field is empty) was (re)discovered at #3548664-7: Some Linker choices have no effect.

Newly discovered by @hooroomoo: #3549034: Shape matching fails on `file` field instances targeting multiple MIME media types (multiple "MIME wildcards").

@lauri confirmed in a call just now we shouldn't try to do all of #3548298: Support linking field types marked SUPPORTED from #3512433 to props in a `ContentTemplate`, and that it's okay to initially ship Content Templates without #3541361: Find optional field instance matches for `type: object` props (images + videos), including for optional fields on bundleless entity types (e.g. `User`'s `user_picture`). So moving both to Non-hard-blocking bugs identified along the way — likely needs product manager decisions and triage.

One more thing for @lauriii to triage/prioritize later: #3522718: [later phase] [needs design] UX for associating mismatched cardinality field instance (too little or too much) with a higher cardinality SDC prop (e.g. `type: array, maxItems: 5`) or lower cardinality (e.g. `type: string`).

Added #3548749: Allow mapping "List (string)" field type to `type: string`, with a twist: don't map the stored value, but its key/name/label, which I extracted from #3548686: Allow mapping "List (integer)" field type to `type: integer` and "List (float)" to `type: float`, which itself came from #3548298: Support linking field types marked SUPPORTED from #3512433 to props in a `ContentTemplate`.

#3547294: Handle when suggestedEntityId node or template is deleted in `ContentTemplate` landed.

#3548165: Components in `ContentTemplate`s and `PageRegion`s are not always rendered in correct order landed.

#3520487: Refuse editing an individual node's component tree (and bring back after 1.0 once exposed slots are allowed) landed and should've been added here. It caused us to discover 2 more issues: #3548854: Add test coverage ensuring consistency on previews markup and live markup when using a content template (added to BE) and #3548859: Warn "Display author and date information" has no effect when using Canvas (for future triaging by @lauriii).

#3546996: Component instances populated by linked `DynamicPropSource`s, but inaccessible entity/field: fall back to `NULL` for these values, triggering fallback rendering landed.

For easier scanning, moved remaining "must have" issues for 1.0 to the top.

#3547598: Refine API response with DynamicPropSource suggestions to provide better UX was missing from the issue summary. Adding it because #3548322: Improve how list of field suggestions is displayed in the UI for `ContentTemplates` and remove `ContentTemplates` from feature flag depends on it.

#3548186: Resolve 500 error caused when editorFrameContext was lost during navigation was missing from the issue summary. Adding it.

#3549034: Shape matching fails on `file` field instances targeting multiple MIME media types (multiple "MIME wildcards") landed.

Just landed #3547598: Refine API response with DynamicPropSource suggestions to provide better UX, which means #3548322: Improve how list of field suggestions is displayed in the UI for `ContentTemplates` and remove `ContentTemplates` from feature flag is now unblocked!

Also, @jessebaker landed #3548186: Resolve 500 error caused when editorFrameContext was lost during navigation yesterday. 👍

Furthermore, in the non-hard-blocking bugs bucket:

• #3546119: Templates menu must be visible for users with the `administer content templates` permission was finished yesterday by @jessebaker!
• And I finished #3548298: Support linking field types marked SUPPORTED from #3512433 to props in a `ContentTemplate` yesterday, and it's now on @lauriii's plate to make decisions, see the overview at #3548298-22: Support linking field types marked SUPPORTED from #3512433 to props in a `ContentTemplate`.

#3548761: Can't link (pick a DynamicPropSource) to populate an optional explicit input if that DynamicPropSource evaluates to `NULL` (typically: field is empty) landed just now!

And IMO #3541054: Require `ContentTemplate`s to have at least one `dynamic` or `host-entity-url` prop source was descoped incorrectly, see #3541054-12: Require `ContentTemplate`s to have at least one `dynamic` or `host-entity-url` prop source for why. 😇

#3548322: Improve how list of field suggestions is displayed in the UI for `ContentTemplates` and remove `ContentTemplates` from feature flag landed, which was the last issue needed to take Content Templates out from requiring canvas_dev_mode to be enabled to just being an enabled feature out of the box, so in a way, the 1.0 scope of this meta issue is done!!!!

Still keeping this meta issue open for the 2 test coverage issues that are still remaining and to settle on #3541054: Require `ContentTemplate`s to have at least one `dynamic` or `host-entity-url` prop source which @Wim Leers and I are still debating on that issue whether to do it or not.

Thanks, @hooroomoo in #97!

#3541054: Require `ContentTemplate`s to have at least one `dynamic` or `host-entity-url` prop source landed!

@lauriii uncovered what seems to be a UI bug that slipped through the cracks for several weeks: #3551665: SDC with "image" + string prop: static image lost upon linking the string prop to a `DynamicPropSource`.

Due to #3545859: Add a `host-entity-url` prop source for linking to the host entity landing at the last minute before RC1 (and it just having gained the missing shape matching + test coverage), there now is a new back-end issue to tackle (#3551455: HostEntityUrlPropSource should be able to support absolute or relative URLs, URL options) and a front-end issue (#3555068: Linking a `HostEntityUrlPropSource` to populate a `type: string, format: uri|uri-reference` in a `ContentTemplate` has no effect).

#3551339: Suggest only relevant DynamicPropSources and #3541361: Find optional field instance matches for `type: object` props (images + videos), including for optional fields on bundleless entity types (e.g. `User`'s `user_picture`) landed. This issue summary is sorely in need of an update from a product owner or product manager.

(I've been told via Acquia channels that both of those issues are crucial to fix before 1.0, but this meta doesn't reflect that. That's very confusing. 🫤)

Newly identified: #3557612: `::matchEntityPropsForObject()` is too naïve: nonsensical `type: object` shape matches and useless labels.

#3557612: `::matchEntityPropsForObject()` is too naïve: nonsensical `type: object` shape matches and useless labels and #3551455: HostEntityUrlPropSource should be able to support absolute or relative URLs, URL options landed yesterday.

#3555068: Linking a `HostEntityUrlPropSource` to populate a `type: string, format: uri|uri-reference` in a `ContentTemplate` has no effect landed just now.

And #3541054: Require `ContentTemplate`s to have at least one `dynamic` or `host-entity-url` prop source was "won't-fixed" on October 14.

#3551665: SDC with "image" + string prop: static image lost upon linking the string prop to a `DynamicPropSource` landed a while ago, so moved it to the Completed list.

#3558719: Linking then unlinking a field renders a wrong Field Widget: corrupt `StaticPropSource` is sent by client, server should detect this is newly discovered. Adding it to the Remaining front-end section though I don't know at this time if it's a front-end or back-end bug.

1. #3548749: Allow mapping "List (string)" field type to `type: string`, with a twist: don't map the stored value, but its key/name/label is making solid progress and nearly done.
2. Added #3533675: Avoid suggesting UNIX timestamp integers for `type: integer` props, which landed today.
3. Added #3563380: Allow linking integer timestamps to `type: string, format: date`: allow `DynamicPropSource` to optionally use a single-input adapter plugin, which is on the verge of landing, and was created from #3548298-25: Support linking field types marked SUPPORTED from #3512433 to props in a `ContentTemplate`

#3563380: Allow linking integer timestamps to `type: string, format: date`: allow `DynamicPropSource` to optionally use a single-input adapter plugin landed last week!

#3548749: Allow mapping "List (string)" field type to `type: string`, with a twist: don't map the stored value, but its key/name/label landed thanks to @penyaskito!

Missed requirement: #3579477: Disallow creating a pattern from component tree with linked props (on ContentTemplates) — currently throws error.