Support all entity types with configurable displays for content templates

The assumption the way this issue is worded is that XB should only allow content templates for entity types and bundles for which XB will be able to allow editing individual entities of. For example, only entity types that implement EntityPublishedInterface. But I wonder if that's correct, so assigning to @lauriii for product-level guidance. Because another way we can go here is to allow content templates for all entity types and bundles, even ones for which editing the individual entities can only be done outside of XB. For example, we could release XB 1.0.0 with the ability to edit content templates for nodes but not yet the ability to edit the individual nodes within XB. And if we can do that for nodes, then why not for content entity types that XB might never provide the ability to edit the individual entities of?

Also, what might make sense here is for XB 1.0.0 to only allow content templates for nodes, and punt any support for creating templates for other entity types (e.g., paragraphs, custom blocks, etc.) to after 1.0.0.

I agree that EntityPublishedInterface seems indeed like a restriction for editing entity content in XB, not to build templates for the entity. I'm wondering if relying on the existence of view_builder for the entity type would be too broad?

Content Templates is still a priority for stable, but we're tracking it separately.

Also, what might make sense here is for XB 1.0.0 to only allow content templates for nodes, and punt any support for creating templates for other entity types (e.g., paragraphs, custom blocks, etc.) to after 1.0.0.

+1 — this is what I was thinking. Assuming we do that, I agree with removing the stable blocker tag, if we first land a basic MR here that does this:

diff --git a/config/schema/experience_builder.schema.yml b/config/schema/experience_builder.schema.yml
index 6e2c4c78f..7aa46c156 100644
--- a/config/schema/experience_builder.schema.yml
+++ b/config/schema/experience_builder.schema.yml
@@ -718,6 +718,8 @@ experience_builder.content_template.*.*.*:
         PluginExists:
           manager: entity_type.manager
           interface: Drupal\Core\Entity\ContentEntityInterface
+        Choice:
+          - node
     content_entity_type_bundle:
       type: string
       label: 'Bundle'

(And then keep the issue open for the wider scope.)

MR up for #7. Assigned to @lauriii for review — if he approves/merges, then I'm happy to remove the stable blocker tag 👍

Adjusting title temporarily for the MR up for review in #9. Once it's in, we should restore the title [PP-1] Validate that content templates are attached to content entity types (+ bundles) that fulfill XB's requirements.

Approved

Hah, the tests are failing legitimately:

Drupal\Tests\experience_builder\Functional\Update\CollapseComponentInputsUpdateTest::testCollapseInputs
Violations exist for Content template xb_page.xb_page.reverse: content_entity_type_id: The value you selected is not a valid choice.
Failed asserting that actual size 1 matches expected size 0.

This is because #3538487: Don't allow passing uncollapsed inputs if using default expression just introduced a ContentTemplate for xb_page — whereas xb_page content entities should never get content templates, because they're explicitly intended for one-off (landing) pages! 😅 This just reaffirms my belief we should strictly validate config.

Thanks, @lauriii!

Because another way we can go here is to allow content templates for all entity types and bundles, even ones for which editing the individual entities can only be done outside of XB.

That'd mean a very bifurcated experience: some things can be edited in XB, some things cannot, etc. It also means going back to the usability reality that has frequently been lamented: being forced to navigate a complex, abstract admin UI where the connections between concepts are hard to discover and hence require a steep learning curve.

We might need to do this eventually to bring support for the full suite of content entity types in Drupal core & contrib. But … I don't think that's necessary at this time. I would urge to pretty please do this in a multi-phased approach:

1. no content template support (the reality in https://www.drupal.org/project/experience_builder/releases/0.7.3-alpha1)
2. node content template support (see #7 and its MR)

   Yes, @lauriii is right in #5 that EntityPublishedInterface is about the content entity editing experience, because XB's current auto-save architecture needs the ability to publish (to work at all).

   While we may very well be targeting only the "pure" ContentTemplate part for 1.0/DrupalCon Vienna, without support for exposed slots, we do need to think ahead towards the future where a site builder creates a ContentTemplate with >=0 exposed slots (typically >=1), and the content author populates those exposed slots in Experience Builder.

   Once that's the case, it'll also be reasonable to expect that the "navigator" in the top bar allows searching not only Page content entities, but any content that can be created or edited in XB, so also for example nodes. And so on and so on. Which is exactly why the list of eligibility criteria in #3498525: [META] Allow Canvas to be used on any content entity type (bundle), as long as it has certain entity type characteristics is what it is.

I'm detaching this from #3498525: [META] Allow Canvas to be used on any content entity type (bundle), as long as it has certain entity type characteristics because at the moment I see adding support template creation for all entity types as a higher priority than adding support for full editing of Nodes within Canvas.

Agreed with that, but since the title says … that fulfill Canvas requirements, we still need to know those requirements anyway. The meta you detached this from doesn't have a final set of requirements though, so we can't really start doing anything here. I see you commented on that aspect in #45 over there, I responded in #46 👍🏓

I'm not convinced that the requirements for creating a content template would have to match those that define which entity types can be authored in Canvas. The real dependency is from #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model to define which content templates can have exposed slots.

Looks like the requirement is to check if entity types have `$entity_type->get('field_ui_base_route')` which is what Field UI does to determine eligibility for site building.

Appreciate the enthusiasm here.
I think we should convert this into a meta. There is no proposed resolution in the IS, and I think this isn't hard but also non trivial, so can result in a huge MR.

AFAIK we need to:

• Identify what really is the requirement for supporting content templates. Per @phenaproxima MR, that might be only being able to have fields (tbf, maybe not even that, as base field definitions might suffice, but it's a good start).
• Expand \Drupal\Tests\canvas\Functional\ApiUiContentTemplateControllersTest to use an entity type different than node.
• In the front-end, componentAndLayoutApi has hard-coded `node` in some places (so far I've found getViewModes, maybe that's the only one? 🎉).
• The listing of content templates in ui/src/components/sidePanel/Templates.tsx assumes: Content Types label + only one accordion. I'd expect we need to have a three level tree now?
• The form for creating a content template in AddTemplateDialog assumes a content templates are only for nodes (hard-coded). We would need a new selector for the entity type first.
• Expand Playwright test coverage in templates.spec.ts.

And I did look into this for 30 minutes. When we are deep into this I'm sure more things will arise. Per the nature of the work (backend vs react) + the amount of changes I'm convinced we should be splitting this.

I forgot the optimist part: on the positive side, lots of the infra for this is in place, and it's generic for entity types as a whole, not nodes. Maybe splitting this would also help to get multiple contributors getting it done during Chicago2026 😇

Updated the issue summary with the details that we discussed at DrupalCon for implementing this.

Worked on it. Preview

Working on words. "content type" needs to be changed to something more dynamic

High-level review posted — I like where this is going! 👏

I'm going to retitle this. We decided the requirement (opted into Field UI). I'm poking at the CI but thisis now reviewable.

I'll work on the failing test and feedback about bundle-less entity types

Addressed test fail + lauri feedback