Prevent fields from being deleted if they are used in Experience Builder fields

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

📌 Prevent modules from being uninstalled if they provide field types used in an Experience Builder field Fixed 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?

1. 📌 Tighten validation: only allow StaticPropSource in XB fields + PageTemplate, DynamicPropSource in ContentTypeTemplate Active 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 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active . 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: 📌 [PoC] Introduce a `ContentTypeTemplate` config entity Active should have introduced the necessary config dependencies already, and it should be up to this issue to add explicit test coverage for it.

🐛 Component trees with dynamic prop sources that introspect field values don't add the relevant fields to their dependencies Active

Obsolete now, see #3518336-32: When a field used by a content template is deleted, any inputs in that template which refer to that field should be replaced with static default values → and #3518336-33: When a field used by a content template is deleted, any inputs in that template which refer to that field should be replaced with static default values → , thanks to 📌 Calculate field and component dependencies on save and store them in an easy to retrieve format Active :)