Content templates, part 2: store a component tree in the template, and allow individual entities to fill in specific slots in that tree

This is quasi-blocked on ✨ Content templates, part 2: Using the templates for rendering Active , in that I'd rather build on the test coverage being added over there than have to scaffold in wholly new test coverage.

But, everything else about that can happen now, so I'll start on that tomorrow.

Wim and I talked about this issue today and we agreed to split it into two issues:

1. This issue, which will add the exposed slots data structure on the ContentTemplate entity itself, with validation. It won't be used for anything yet.
2. In another issue, the entity-side storage for what goes into the exposed slots. Wim feels that this should involve making the component_tree field item support infinite cardinality, and adding a nullable slot_name column to it. This is appropriate for a number of future-focused reasons that Wim articulated to me, along with making it much easier to detect if a content creator is about to make a destructive change that will affect exposed slots in extant entities.

The only work still needed here, I think, is making sure that only the content templates for the full view mode actually allow exposed slots. Hopefully this can be done with some config schema magic, but it might call for a new validation constraint.

So I cannot use config schema by itself to enforce that exposed slots are only allowed in the full view mode, for a couple of reasons.

• This is a config entity, which means there's always an exposed_slots property, even if unused. If it's present (which it will be) in content templates in other view modes, those are automatically config schema errors.
• experience_builder.content_template.*.*.full cannot resolve to a type unless it was also based on some kind of meta-type like experience_builder.content_template.*.*.[view_mode]. There's precedent in core for something like this (editor.schema.yml), but not for config entities.

The proper path here looks like a validation constraint at the entity level which confirms that exposed_slots is empty in a non-canonical view mode. I think it probably makes more sense to just graft this into the ValidExposedSlot constraint.

Opened ✨ Content templates, part 3b: store exposed slot subtrees on individual entities Active for the entity-specific stuff.

#9 Thanks so much for writing up your research in detail! 👏🙏

• experience_builder.content_template.*.*.full cannot resolve to a type unless it was also based on some kind of meta-type like experience_builder.content_template.*.*.[view_mode]. There's precedent in core for something like this (editor.schema.yml), but not for config entities.

But Editor is a config entity too, so that does seem fine?

• This is a config entity, which means there's always an exposed_slots property, even if unused. If it's present (which it will be) in content templates in other view modes, those are automatically config schema errors.

That's a great point! So given that, the best we can do anyway is to restricted exposed_slots on view modes other than full to the empty array. And we need a validation constraint anyway. So then doing what you did here seems reasonable.

But Editor is a config entity too, so that does seem fine?

Editor uses this pattern for a subset of its values (image_upload.1 and image_upload.0), but the config schema type for the whole entity is not polymorphic.

Two threads are still unresolved, but they need answers from Wim (or someone else knowledgeable). Otherwise this is probably ready, as far as I can tell.

Not passing tests.

nit: "For nodes, that's the full view mode."

It's not just nodes, technically the canonical view mode is always "full" per the default parameter value of \Drupal\Core\Entity\EntityViewBuilderInterface::view and \Drupal\Core\Entity\EntityViewBuilderInterface::viewMultiple

Tests are passing now, validation and test cover looks solid.

Looks fantastic!

The only thing that was inaccurate was the distinction between

1. the machine name of the component slot that is being exposed (e.g. the "two column" SDC's column_one)
2. the machine name of the exposed slot itself, i.e. the name being picked by the Content Template author

which per the example in the config schema are two different things:

          # exposed_slots:
          #  profile_bio:
          #    label: 'Profile Bio!'
          #    component_uuid: 28bcab26-e434-4ad4-9eaf-0520bdb32fcc
          #    slot_name: column_two

👆 profile_bio is the machine name of the exposed slot, column_two is the name of the component slot.

I clarified that.

What added to that confusion is that XB is not yet sufficiently restricting this across ComponentSource plugins, so created 📌 Constraint slot names allowed by XB in its component tree Active for that!

🚢

wim leers → credited penyaskito → .

Automatically closed - issue fixed for 2 weeks with no activity.