[META] Introduce a `ContentTypeTemplate` config entity + related infrastructure

Updated issue summary with new design/product questions that I identified while building the PoC to predict future technical challenges: now there's not 2 but 9 challenges! 😅

FYI: I landed on the term Content Type Slot for what @jessebaker alluded to in #3498819-5: [Needs design] Adjust representation of Regions in the Layers UI.

Note that I built this config entity type PoC while taking into account all discussion-surfaced requirements outlined in the meta.

Omitted from the work I did:

• Per-component input (un)locking: this seems too overwhelming/too granular.
• Mostly omitted: view mode concerns. The config entity type supports storing it, but none of the semantical or UX consequences are addressed. For example: it the XB content type template for a "teaser" view mode exposes a different Content Type Slot than the one for the "default" view mode, how would the content author ever populate it? It'd always remain empty! An obvious solution seems: the "default" view mode defines the total set of Content Type Slots, and each view mode can choose to contain only a subset of them. But does this meet @lauriii's product vision? Impossible to tell: it's currently neither written down nor expressed in designs. He did express that anything beyond "default" view mode is a concern for later, so I didn't delve deeper.

In not-yet-public docs, I encountered a functional requirement I had not read before, but it makes sense (it ties into XB product requirement 14. Configuration management), it reads:

I can make changes to the content type templates outside of the production site

… which is the non-UI, but config-management-level-enforced equivalent of point 9 I surfaced in the issue summary above: Once content exists that populates a Content Type Slot, it can NEVER be removed (its label can still change though), otherwise values in individual content entities' XB fields would disappear.

Additional notes while digging into this problem space and trying to think through everything:

10. 🪄⚜️Translatability. A component tree will typically contain some static values. For example: a button that points to the current content entity's webshop URL, with that URL being mapped into it dynamically (DynamicPropSource), but the button label being defined statically because it makes no sense as structured data (so: StaticPropSource).

    Any component input populated using a DynamicPropSource is automatically translatable, because it fetches the value from the host content entity.

    But any component input populated using a StaticPropSource is NOT translatable. At least not at this time. Because component trees in config are currently enormous JSON blobs. That's not compatible with Drupal's config translation functionality.

(More to follow.)

Based on discussing #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model with @lauriii this morning, a few things surfaced:

1. Changing/deleting Content Type Slots MUST be allowed even if it results in user-entered data being "lost" (it still exists, just won't be visible anymore). In fact, it MUST explicitly delete such "lost" data upon re-saving the content entity.

   Per @lauriii, this is necessary to allow iterating on XB Content Type Templates. There MUST be a "heavy" warning, an explicit confirmation by the Site Builder, but this must be allowed.

2. Supporting multiple view modes MUST be supported from the start. But, only the default view mode will be customizable per entity. So, a teaser view mode for example would look the same for all entities of that content entity type+bundle: the same exact XB component tree would be used for all (i.e. the one in the "teaser" Content Type Template config entity), while of course resolving the structured data mapped into the component tree (i.e. using DynamicPropSources).

   This avoids the entire "keep Content Type Slots in sync across all Content Type Templates (one per view mode) for this content entity type+bundle" problem. 👍

3. XB is used for either all or none of the view modes. IOW: as soon as you chose to use XB, all existing EntityViewDisplays are ignored. Those that don't have an XB Content Type Template defined yet render nothing.

   Note: this will change in the far future per @lauriii: he intends to allow specifying an XB element (see #3455036: Clarify "components" vs "elements" vs "patterns") to be associated with each field type, which essentially becomes the XB equivalent of "the default formatter".

4. Last but not least: per @lauriii, there won't be a "search" or "search index" view mode for XB — search must be configured to use the "default" view mode's representation of content entities both for 1) crafting a search index to power the search, 2) presenting search results. Related: #3462219: [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters and #3483301: Create a configurable search api processor for XB data.

   It's not clear to me yet how that avoids the

   but without elements that would 'pollute' the search results like field labels, related content blocks, CTAs, social widgets etc. so that if I search for "newsletter" or "Facebook" I don't get every article on the site back in the results, but only the ones with content actually mentioning newsletters or Facebook.

   problem described in #3462219: [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters, though.

Reflected #7 in the PoC MR: https://git.drupalcode.org/project/experience_builder/-/merge_requests/7....

I see that I failed to update the issue summary with @lauriii's input from #7. Now updated. Some questions are fully answered, some are merged.

#10:
RE: your question: per discussion this morning with @lauriii: as the Site Builder modifying/creating an XB Content Type Template, you have complete freedom to completely change your mind about adding/removing exposed Content Type Slots. So the answer is: "yes, you can revert".

1. ✅ Sorry 🙈 This has changed — see #7.2. Issue summary updated in #11 👍
2. I suspect we are on the same page, but … I disagree with your specific wording 😇 I know I'm gonna sound super nitpicky, but all of this is going to have enormous consequences for UX and data integrity, so I went to be painfully precise 🤓 😜
   • It should not be "any slot", because slots can live within other slots.
   • Furthermore, I'm not convinced yet that only slots must be exposable as a Content Type Slot, but any component instance. That way:
     • if it's a component instance without slots, it means you can modify this component instance's inputs — for example: XB's my-section SDC would then be able to have inputs (image, text next to the image) that are defined in the Content Type Template, but if the Content Creator chooses, they could modify the inputs without the ability to add more component instances
     • if it's a component instance with >=1 slot(s), it means the Content Creator can modify as much as they like: remove the entire component tree in one of those slots, keep it empty, replace it with other component instances, or keep it all the same as in the Content Type Template
3. ✅ This has been answered by @lauriii. Issue summary updated in #11 👍
4. 👍 WFM! But would there then be affordances to ensure the Site Builder is explicitly aware of which fields (whose values) are not (yet) being presented?
5. ✅ This has been answered by @lauriii. Issue summary updated in #11 👍
6. 👍 This ties well into what @lauriii has confirmed Product-wise — see the updated information for Question 2 in the issue summary.
7. 🤔 I'm not sure how to interpret this. Are you saying that a Site Builder should or should not be able to expose a Content Type Slot that contains some component instances populated with structured data?
8. 👍
9. ✅ Sorry 🙈 This has changed — see #7.1. Issue summary updated in #11 👍
   (And no, that's not what I meant: I was referring to disallowing deleting Content Type Slots, but @lauriii has since said this is fine, and it's fine to lose Content Creator-crafted data.)

This blocks pretty much everything in #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model.

In more concrete terms, it blocks #3452848: [PP-1] Test coverage to prove configurable fields cannot be deleted from content entity types if they are used in XB Content Type Template.

#17: that's not matching what you said earlier.

Unless you meant that that would be the initial state, and you intend to only use the default content type template for search indexing and a different content type template for presenting search results?

But if we do that, then it follows that the information that was matched is absent from the search result's presentation, meaning highlighting is impossible.

Layout builder uses third party settings on the entity view display for this rather than a separate config entity.

I considered that, but I think there are strong reasons against it:

1. The consequence of that will be though that this new config entity type is not validatable, because EntityViewDisplay config entities are not yet fully validatable, with an unclear ETA for that in core. This would significantly weaken XB's 14. Configuration management product requirement.
2. LB predominantly uses field formatters to present structured content: it uses FieldBlock, which contains field formatter settings (which IIRC are treated as the default formatter settings when placing a field block). So, most of the information in the EntityViewDisplay is still somewhat relevant when using LB.
3. @lauriii has indicated that it should be possible to try XB and be able to abort and go back to what you had before: plain core entity view displays, or Layout Builder entity view displays. Not touching them at all makes that an easy promise to keep.
4. Finally, and probably the strongest argument: LB does a quite heavy-handed override at \Drupal\layout_builder\Hook\LayoutBuilderHooks::entityTypeAlter() that causes all EntityViewDisplay config entities to use its own LayoutBuilderEntityViewDisplay class instead! XB cannot do the same, or it'd either break LB (race: who wins?) or require LB (definitely not the intent either). That's in the MR:
   

    * This MUST be a new config entity type because doing something like Layout
    * Builder's `LayoutBuilderEntityViewDisplay` is impossible if XB wants to
    * provide a smooth upgrade path from Layout Builder, due to
    * \Drupal\layout_builder\Hook\LayoutBuilderHooks::entityTypeAlter() — only one
    * module can do that!
   

I don't think #3462238: Decouple tree storage, introduce tree storage plugins is a hard blocker for this issue, but I definitely agree it'd be nice to solve, especially in light of providing a smooth transition from Layout Builder into Experience Builder! (Note this will require either duplicating LB's FieldBlock in XB, or moving it to another module — otherwise Layout Builder will be required forever even on sites that have all their data moved from LB to XB!)

@callumharrod walked us (@lauriii, myself and David Bee) through the designs he crafted. All of us asked various questions. The PoC here is still aligned with the designs, with one exception: we're not going to be exposing a component instance as an exposed slot, but a slot in a component instance.

Walked @phenaproxima through that change, and captured this change with him together, as a way to hand this off to him: https://git.drupalcode.org/project/experience_builder/-/merge_requests/7... 😊 (I'm still around, obviously!)

Basically, content type template config entities will look like this:

langcode: en
status: true
dependencies: …
id: node.article.teaser
content_entity_type_id: node
content_entity_type_bundle: article
content_entity_type_view_mode: teaser
component_tree: …

and the one for the default view mode will be able to specify content type slots on top of that:

langcode: en
status: true
dependencies: …
id: node.article.default
content_entity_type_id: node
content_entity_type_bundle: article
content_entity_type_view_mode: default
component_tree: …
exposed_content_type_slots:
  profile_bio:
    label: 'Profile Bio!'
    subtree:
      instance: 28bcab26-e434-4ad4-9eaf-0520bdb32fcc
      slot_name: column_two
  outro:
    label: 'Outro'
    subtree:
      instance: 98bcab26-e434-4ad4-9eaf-0520bdb32fcc
      slot_name: body

@phenaproxima has split this into multiple child issues 👍

Epic work on #3517741: Content templates, part 1: introduce the `ContentTemplate` config entity type, @phenaproxima — it is in! 😄 🚀

Also: detailed guidance/pointers at:

• #3518336-2: When a field instance used by a `ContenTemplate` is deleted, or a field-type providing module is uninstalled, replace affected `inputs` with default `StaticPropSource`
• #3518248-6: [PP-1] Content templates, part 4 (boss battle): create a UI for editing templates

FYI: #3518336: When a field instance used by a `ContenTemplate` is deleted, or a field-type providing module is uninstalled, replace affected `inputs` with default `StaticPropSource` has been fixed 🥳

Update for #29:

• #3518336: When a field instance used by a `ContenTemplate` is deleted, or a field-type providing module is uninstalled, replace affected `inputs` with default `StaticPropSource` is fixed
• #3519352 is unblocked, and is in need of review by @phenaproxima at #3519352-55: Content templates, part 3b: store exposed slot subtrees on individual entities

I think this meta issue has served its purpose.

As this meta issue's summary says: This is in support of #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model — and the design + product decisions have been made, the config entity type exists, the fundamental infrastructure exists thanks to @phenaproxima:

• #3517741: Content templates, part 1: introduce the `ContentTemplate` config entity type
• #3518013: Content templates, part 2: Using the templates for rendering
• #3517845: Content templates, part 3a: allow content templates to define exposed slots
• #3519352: Content templates, part 3b: store exposed slot subtrees on individual entities
• (and several follow-ups for several of those issues)

… with now a subset of that infrastructure getting a UI built before 1.0 — see #3541000: [META] Content templates UI for 1.0: only nodes, no exposed slots, no replacement for the view mode/display UI

We still have #3455629 around for delivering the full scope — see #3455629-51: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model.