#Configuration schema

So, rephrasing: assuming that we know which of the structured data are "meta" vs not, must every non-meta field be used somewhere in the component tree?

It's common to have fields that are only used on specific view modes, including ones that don't show on the default. An example would be a 'short summary' field that only shows on a card view mode and not on the main content.

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

1. 🪄⚜️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.)

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: .

Conflict was on cspell word list. Rebased, keeping rtbc

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

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 for what @jessebaker alluded to in #3498819-5: [Needs design] Proposal: 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.

Before

After

"EntityTypeExists" We actually used a similar constraint in book contrib so glad to see this is going to be part of core.

Did a review of the code changes and nothing stands out and comments appear to be functioning just fine (11.x standard profile install locally).

LGTM

Found the tiniest of nitpicks, this is just a version number change in the deprecation, so leaving at rtbc.