@callumharrod

The undo/redo buttons might come back in a future iteration of the design - likely in a context menu or something. The tests should probably be updated to work assuming the buttons are not visible in the UI at all times.

Responses

Hey @wim-leers - the answers below is just my take on the problems listed 😄

1. View modes - Not for me to answer
2. Internal/exposed or Locked/unlocked aka Exposed Content Type Slots aka unlocked subtrees - Any slots that are used within the template should be able to be an exposed slot. They will not be able to be exposed if they currently contain any child items.
3. What about the existing EntityViewDisplay(s)? - Unsure on this one, would be keen to discuss it further.
4. Must every field for the content entity type+bundle be used somewhere in the component tree, because otherwise some data is invisible? - No, it would be up to whoever is creating their content template to decide what fields are mapped to their template. For example: If a product content type has a required field of ‘Price’ it is up the person creating the template to ensure that it is tied to their template.
   I think a good way to think of the creation of templates is similar to how it would be done with a headless CMS, in that the content model and content creation are separate from the templating layer.
5. Are we okay with either ignoring or breaking existing hook_entity_display_build_alter() implementations? - Not for me to answer
6. Gotcha for Exposed Content Type Slots aka unlocked subtrees. - Correct, we should allow having no exposed slots for the content type.

   If a user wanted to they could make the entire page a single slot, but they would still need to add a component and expose the slot in the exact same way as exposing any other slot.

7. Gotcha for Exposed Content Type Slots aka unlocked subtrees. - I don’t believe we should be allowing exposed slots to include anything. By including items in a slot to also be exposed to a content editor, we open lots of ways to break templates that aren't necessary. By going this route I don't think we impede the template builder in any way. In the user flows this should become clearer.
8. Gotcha for Exposed Content Type Slots aka unlocked subtrees. - Good point, as part of exposing a slot, we can ensure that there’s a name and machine name here. Will need some designs and work on the front-end to cater for this.
9. Gotcha for Exposed Content Type Slots aka unlocked subtrees. - Are you saying that when a component is added to a slot when editing content, it cannot be deleted? Or is it just that the data cannot be deleted?

Questions from me:

1. Once you have made a slot exposed, are we able to revert this change? Can we turn off an exposed slot?

Adding two screenshots from the Figma designs showcasing what the layers panel currently looks like. For pages we are only showing the content region and it's items. No other regions are surfaced to the user currently, however, I will be looking at how we expose regions when you are creating a template for a content type.

Here it shows what it looks like when a region is selected:

Here it shows what it looks like when a component inside of a region is selected:

balintbrews → credited callumharrod → .

balintbrews → credited callumharrod → .

Hey @tedbow this could do with a review please 😊

callumharrod → created an issue.

callumharrod → made their first commit to this issue’s fork.