Prevent fields from being deleted if they are used in Experience Builder field's dynamic prop values

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 🌱 [META] Configuration management: define needed config entity types Active 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.

Wim Leers → credited larowlan → .

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 🌱 [META] Configuration management: define needed config entity types Active .

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:

• 📌 "Developer-created components": mark which SDCs should be exposed in XB Fixed 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...

#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).

📌 [PP-1] Prevent modules from being uninstalled if they provide field types used in an Experience Builder field Postponed is in.

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

@Wim might be worth continuing the discussion on ✨ JSON-based data storage proposal for component-based page building Active then feeding that back to here?