[PP-1] Test coverage to prove configurable fields cannot be deleted from content entity types if they are used in XB Content Type Template

Something needs to exist to map field_something to dynamic-static-card2 unless content editors are going to be manually specifying named fields every time they add a dynamic-static-card2. If that is a config entity as larowlan is suggesting in #3444424: [META] Configuration management: define needed config entity types and elsewhere, then the field type would be a config dependency, and therefore impossible to delete unless the config entity is deleted.

However the overall problem for this issue to solve would still be there, in that now it would be necessary to prevent the deletion of the config entity if it's used in an xb field. But it means the dependency is on something different then.

This is indeed essential too. But it's not so much a bug as it is a thing we absolutely have to do before there can be releases. We're still in the early build phases :)

#2: @larowlan is right, the default component tree for entities of an entity type bundle will be defined in a config entity type, which means you're right: config dependencies will prevent this from happening.
But content creators will still be able to add additional components (if the aforementioned config entity indicates that is allowed, and in which places, etc) or even override some (again, depending on that config entity), so this issue will still be necessary for those cases.

But content creators will still be able to add additional components (if the aforementioned config entity indicates that is allowed, and in which places, etc)

Why? Wouldn't that list of components also need to be configured somewhere? Just adding any component available in the codebase could cause a lot of problems per discussion in #3444424: [META] Configuration management: define needed config entity types.

or even override some (again, depending on that config entity), so this issue will still be necessary for those cases.

As in override formatters, or something else?

Wouldn't that list of components also need to be configured somewhere?

Yes:

• #3444417: "Developer-created components": mark which SDCs should be exposed in XB is the first step — this config entity type will define which components are exposed within XB
• later, it may become possible to define at the entity type+bundle level which components are allowed … or perhaps even per slot? All TBD. See 17. Restricted components at https://docs.google.com/spreadsheets/d/1OpETAzprh6DWjpTsZG55LWgldWV_D8jN...

As in override formatters, or something else?

TBD, the equivalent of Layout Builder's per-node overrides (the exact details of which I'm not familiar with), where you can choose to deviate from the default layout configured (imposed) at the node type level.

#3444417: "Developer-created components": mark which SDCs should be exposed in XB is the first step — this config entity type will define which components are exposed within XB
later, it may become possible to define at the entity type+bundle level which components are allowed … or perhaps even per slot? All TBD. See 17. Restricted components at

Right so between these two, all possible fields/widgets/formatters available in XB are configuration dependencies of one or more of these config entity types. This means that configuration dependencies should prevent uninstall.

This would still leave the situation of trying to remove a component from the list of available components that's in use, but that means searching xb field data for component usage, not field usage then.

TBD, the equivalent of Layout Builder's per-node overrides (the exact details of which I'm not familiar with), where you can choose to deviate from the default layout configured (imposed) at the node type level.

But if layout sections, and the content of those sections, are all components, then this would all be covered by the use cases above.

The only thing not covered would be making up entirely new components on the fly (like using a different media view mode in a hero image on exactly one node, without making this available anywhere else as an option).

#3450957: Prevent modules from being uninstalled if they provide field types used in an Experience Builder field is in.

@catch: I have to call it a day, I'll respond to #9 later.

@Wim might be worth continuing the discussion on #3440578: [PP-2] JSON-based data storage proposal for component-based page building then feeding that back to here?

1. #3481720: Tighten validation: only allow StaticPropSource in XB fields + PageTemplate, DynamicPropSource in ContentTypeTemplate started forbidding DynamicPropSources from being used in XB fields (i.e. in a specific content entity's XB component tree).
2. I'm working with @lauriii to refine the plan for #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model. The direction that is going, it looks like the tightened validation we introduced in #3481720 will become permanent.

That means that the issue title/scope here is wrongContentTypeTemplate will simply have to reflect every DynamicPropSource in its component tree as an explicit config dependency.

If we do that, then Drupal's config dependency system takes care of this problem for us! We should still confirm it with explicit test coverage though, and that's what this issue is about.

IOW: #3511366: [META] Introduce a `ContentTypeTemplate` config entity + related infrastructure should have introduced the necessary config dependencies already, and it should be up to this issue to add explicit test coverage for it.

#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`

Obsolete now, see #3518336-32: When a field instance used by a `ContenTemplate` is deleted, or a field-type providing module is uninstalled, replace affected `inputs` with default `StaticPropSource` and #3518336-33: When a field instance used by a `ContenTemplate` is deleted, or a field-type providing module is uninstalled, replace affected `inputs` with default `StaticPropSource`, thanks to #3457504: XB field type: calculate all dependencies, store them, surface in new Component "Audit" operation :)