[PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model

This is great, thank you so much Wim. I've read through all notes so far and it's cleared up quite a few questions I had.

On the note of CC freedom, I think one thing that would be ideal (and I'm pretty sure is covered but there is a bit of nuance) is having the ability to be able to configure the amount of freedom per region per layout per bundle. As in at level in bold, as a site builder, I want to be able to configure the "freedom" of the CC.

This is essentially what Layout builder restrictions (and lock I believe) modules allow you to do. I know those layers are named differently I'm XB but I believe there's a similar concept (although XB allows more nesting).

Ideally, also, let's try and make the UI for configuring this good for the site builder 😅

For A): in a content type template, it's possible to mark slots as "unlocked", meaning the Content Creator can add additional components to it (later also with restrictions, see 17. Restrict nested components)

I think I understand this - say an article with author, submitted, main image, standfirst, at the top, but then arbitrary amounts of text and/or images and/or sidebars underneath, and then maybe with a templated related articles + social sharing block at the bottom too.

👆 For A): in a content type template, it's possible to mark component subtrees as "unlocked", meaning the Content Creator can change that component subtree (later also with restrictions, see 17. Restrict nested components)

But I don't understand what this is at all. Is it possible to add a concrete use case?

C) which fields in the content type (i.e. FieldConfigs) do not yet have a representation in the

Assuming we do #3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points (and then whatever the SDC version of that might end up being), this could happen when you select which field is used in a field block (or which prop after selecting a component), so we don't have a list of possibly useless fields like revision log messages in the sidebar.

the static prop values in the right sidebar, to edit them — if a placed component is selected on the canvas with >=1 unlocked static prop

Why is this necessary vs. a default value for a field (or a value to use when the field is empty)? I can see a use-case for non-editable arbitrary content in a bundle layout, views blocks for example, but also maybe a heading or something. However that would never, ever make it into entity content - it would appear only in the bundle config. Once something becomes editable, how is it providing anything genuinely different from what you can (or potentially could) do with a field value?

@lauriii indicated in that discussion that creating a content type template should not be a required step. How is that possible? Does that mean starting out with an full-creative-freedom canvas?

If components are defined by bundle, then I could see it being a blank sheet template where everything is done per-entity - i.e. a 100% override all the time. But this would mean that content editing would have to be done in layout builder/XB - if you only filled out field values (UI or API), nothing would show up at all then. I think this is a valid use case for a 'landing page' bundle where the overall structure is completely arbitrary even if common components are used within that.

I recorded a video with my thinking around this, approaching it from a slightly different angle: https://www.youtube.com/watch?v=l0LWqoqFmBY. I'm walking through two diagrams on that video; one for data sources + design system and one for breaking down a content type.

On the note of CC freedom, I think one thing that would be ideal (and I'm pretty sure is covered but there is a bit of nuance) is having the ability to be able to configure the amount of freedom per region per layout per bundle. As in at level in bold, as a site builder, I want to be able to configure the "freedom" of the CC.

If I understand this correctly, instead of configuring which components are available for a bundle, you'd like to configure slot restrictions for a specific component within a specific bundle. Do you have specific example scenarios where this is needed that you could walk us through?

Edit: I realized I had forgotten the JSON data source from the first diagram. It has been added to the diagram but it's missing from the video.

I just watched the video in #19 and have two main questions. Most of the locked vs. slots stuff makes loads of sense to me. Not sure I understood the 'default value for a slot' idea before but do now!

I'm not sure I know what the advanced use cases are that this doesn't cover yet, might be good to explicitly list what those are at some point so the constraints are clear.

The two things I didn't get:

1. Maybe it's implicit, but I didn't see a mention of components in templates that are locked but may not have a value. e.g. in the example the image field could be optional, but if it's populated, then the image always gets rendered in the same place. The 'image in slot' concept would allow you to remove the image from there but still add a field value which is either not used, or used in a component added in a slot elsewhere. But this is different from the image always being in the same place, but maybe not having a value. Optional fields are already supported in layout builder and view mode config. Would be good to clarify that's not going away.

2. I'm afraid I still don't see the reasoning for 'static props in entity content' in that video, the various paragraph data, accordion etc. could still be stored as multi-value fields on the entity.

#21.2: Hm … I was hoping that the video starting at https://youtu.be/l0LWqoqFmBY?si=6dKplDCnX340mnuK&t=422 would clarify this sufficiently, especially combined with the last paragraph of my comment in #20.
If the combination of the video + that paragraph doesn't connect the dots sufficiently

I think I understand why people think it's necessary, but also I think I disagree with it for specific reasons, but I'm not sure I've clarified what those objections are enough (or that it's been lost in the barrage of issues + comments).

so it would not make sense to pollute the data model with optional fields for all of these.

possibly sums up the disagreement.

Let's take an example building on the university degree course content type from the video.

The university site builder adds a 'Testimonial' component, this has:

student image
student name
student testimonial

Something like: "Michelle ~ This course gave me a great foundation in computer science and I found a job a month after I received my degree".

This is not included in the view mode template config at all, it's just one of the options for content editors to use in slots, designed to be interspersed with other elements to break things up.

At first, this is only intended to be used in the optional slots on the default view mode, but later on, they decide that the listings pages (the teaser/card view in the video) should show a testimonial too.

If that testimonial component is backed from field data from the beginning, then the site builder can immediately configure the 'teaser/card' view mode XB template (or just regular manage display) and add the first (or random potentially) delta of testimonials in. It's all ready to go, the site builder never had to make an up front decision based on what may or may not become a requirement later, or learn the difference between field backed and static components before they could start building their site successfully.

If it's using 'static props', then it will only exist in the XB field data for the default view mode, and be inaccessible when configuring other view modes.

They're then left with (at least) three (bad to very bad) options:

1. Add another testimonial component, this time field backed, to the content type, and manually or via an update hook, migrate the content from static props to fields.

2. Some horrible hack where they try to parse out the testimonial from the default view mode xb field content to use on the teaser.

3. Add a slot to the teaser/card view mode, that allows a testimonial to be added, and duplicate the data manually between the two view modes.

Two more questions based on the video in #19:

In the video, there's a component in a slot which uses an entity reference. Is this:

a. An entity reference + view mode selection - with the specific layout/component coming from the view mode.

b. An entity reference which is then manually mapped to props on a component selected by the content editor?

And regardless of the answer to a. or b., is the intention to support both?

---
With default components in templates (the image in a slot), is the default value always stored with the entity? i.e. if the default was changed from an image to video later, I am assuming that all the existing content that did not customize the slot would still have the image, because it's a default value which then gets saved when the entity is saved. Not sure that's 100% correct interpretation though.

In the video, there's a component in a slot which uses an entity reference. Is this:

1. An entity reference + view mode selection - with the specific layout/component coming from the view mode.

2. An entity reference which is then manually mapped to props on a component selected by the content editor?

And regardless of the answer to #1 or #2, is the intention to support both?

The example of content composition I showed, I'd imagine falling under #1. However, we're aiming XB to support both of these.

With default components in templates (the image in a slot), is the default value always stored with the entity? i.e. if the default was changed from an image to video later, I am assuming that all the existing content that did not customize the slot would still have the image, because it's a default value which then gets saved when the entity is saved. Not sure that's 100% correct interpretation though.

The default value is stored with the entity, so if the default was changed later, it would remain intact on existing content.

What does this mean? The per-view mode default layout?

I mean layout plugins, usually defined in our theme (or modules) foo.layouts.yml

Do you have specific example scenarios where this is needed that you could walk us through?

Definitely, we use Layout Builder Restrictions on basically every project that uses LB - it's essentially a mandatory module IMO if you're allowing layout overrides.

One way we use it is something like this:

Say we have 2 bundles - Basic Page (BP) and Landing Page (LP).

We have 3 Layouts defined in our theme - Sidebar , Cards, and Edge.
Sidebar is an 80/20 split layout with regions "main" and "aside"

Cards is a variable layout that allows some full width content with a variable number of columns of "cards" underneath (see Lee's blog post for more info on this) with regions "intro" and "cards"

Edge is a full bleed layout that expands across the whole page with only 1 region "main"

With LB Restrictions I can setup the following config:

On BP content
Only allow the Sidebar layout, do not allow Cards or Edge.
On the Sidebar layout, only allow certain components in the main region and certain components in the aside. E.g I do not want CCs adding my right hand menu to the main region, and I don't want image cards in the aside.

On LP content
Allow all layouts
Apply the same rules as BP content to Sidebar layouts, and maybe allow an additional component (because it should allow different permutations per bundle)
On Edge layouts only allow a "Hero" component - taking it a step further it could be ideal to restrict this to only a single Hero component and nothing else (this extra bit currently isn't possible with LB restrictions afaik)
On Cards layouts only allow simple Text components in the Intro region, and Card components in the Cards region.

Forgot to reply to this:

Essentially this is a more complex variant of unlocked slots (which you mentioned above). I'm not at all certain it is a good idea! It was discussed at some point (maybe even just at DrupalCon — I do not recall). It kind of falls under the " I'm not saying I think this is a good idea. This is more on the extreme end of granularity of control." caveat I wrote in #2.

Which was a reply to @catch's question about unlocking only certain slots in #18

As per above in #26 I think this kind of flexibility is a good idea and somewhat required. In my example above we could imagine that on the Basic page maybe the Sidebar region (or slot?) of the 2 col 80/20 layout may be locked. E.g I can imagine a use case where I want CC to be able to edit the main region of that 2 col layout, but I want to lock the sidebar to only ever display the right hand tree navigation component, and nothing else.

Two further questions on this:

1. Right now XB only enables one XB field instance per bundle, but if unlocked slots are ever allowed on the non-default view mode, wouldn't it need to be a field-per-view-mode-with-unlocked-slots? Or all view modes stored in one field value with an additional layer of JSON nesting?

2. Note #3440578-80: [PP-2] JSON-based data storage proposal for component-based page building where I tried to think through 'special' view modes like search (indexing) and newsletter rendering - which usually show nearly the same content as the 'default' view mode but with certain differences like related content blocks or field labels removed. This gets very, very complicated with the current data model and unlocked slots. If we allow unlocked slots in multiple view modes, it could get even more complicated - e.g. say someone makes an unlocked slot in the teaser view mode for an article content type, and you then want that search indexed along with the unblocked 'body' slot on the article view mode.

I was also unable to find internal search indexing and multi-channel re-use such as e-mail in the product requirements.

I unfortunately thought about search indexing/newsletters several hours after talking to @lauriii about XB at devdays, have opened an explicit issue at #3462219: [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters so it can be tracked in its own right.

However one thing that came up when we talked is that most of the experience builders don't actually have a concept of view modes at all - you create the data, and then it gets put out as JSON, and then the front end templates just consume the bits of the JSON they need (full, card etc.), but the idea of having separate configurations for different view modes is not really in there. (hopefully this is an accurate summary of what was said).

So I think the question is: how do we keep unlocked vs locked slots in sync across the different templates?

I would assume locked is fine, because there is no editing of something that is locked, it's just bundle + view mode level config.

But yeah once you have unlocked slots in more than one view mode there is a lot to deal with. One way to deal with it would just be to prevent it everywhere except full/default.

I am working on #3481720: Tighten validation: only allow StaticPropSource in XB fields + PageTemplate, DynamicPropSource in ContentTypeTemplate. Since we are removing dynamic properties we didn't need some of the logic and test coverage we added in #3454257: Allow Experience Builder fields to support Asymmetric and Symmetric translations.

Basically since you can't display a field like the node title in the XB field it you can't get the wrong translation of the title. You can still have different component properties per language, they will just all be static props

But this current issue will need some of the logic and test coverage we removed added back. Particulary this https://git.drupalcode.org/project/experience_builder/-/merge_requests/3.... I assuming the same fix will be needed and work but to be sure we will need to update the test coverage we removed in \Drupal\Tests\experience_builder\Functional\TranslationTest in #3481720

The test/use case won't be exactly the same but basically we will need to test if you use the node title in a component prop in the content type template when view a single node in different languages you see the correct translation of the title

We will also need to determine if we will support config translation of content type templates. If so that will be another area to test

FWIW @DanielVeza has been working on a LB solution for this at https://www.drupal.org/project/lb_immutable_sections

Tagging this as a stable blocker. In order for XB to be a viable replacement to LB/Paragraphs this is needed.
Otherwise we're in https://xkcd.com/927/ territory.

Also linking pieces that will make this easier. There is a lot we can learn from LB on this front.

thanks Wim

tagging for findability

This has been partially covered above and may be part of the video from #19, but I just wanted to have my thoughts in written format from pain points experienced with Layout Builder and overrides. As flagged by this being a stable blocker so I'm happy this is on the radar, I think its something that XB needs to get right (to the best of our ability) from the start. I'm going to use Layout Builder terms in this comment but the same logic should apply to their XB equivalent.

Note that this is going to be a braindump and going to be a bit rambly.

Layout Builder is a fantastic tool, and the contrib community around has built tools to further support how it works. Where Layout Builder falls over however, is getting updates from the default template to nodes that have been overridden.

Lets say we have a content type with 5 sections in it's default template, and 10,000 nodes of that content type where most if not all have been overridden to add additional content on a per node basis. Now we need to add a new block to section 3 for legal or compliance reasons.

This new block is not going to appear on any of the overridden nodes, so we need to write a complex update hook to add it everywhere. However there are still problems here. We can't guarantee that section has not been deleted or moved on any of the overridden nodes, so we need to take that into account. Layout Builder sections don't have UUIDs (#3208766: Add UUID to sections, so we can't even look up the section during the update process with confidence. This is very flaky so we tend not to do it.

Because of this on some new projects I've started to create blocks that renders a collection of fields/blocks, so the Layout builder content now looks like this.

-- Top content (Collection of blocks in a single plugin)
-- Layout Builder content
-- Bottom content (Collection of blocks in a single plugin)

This means the editors lose some control over what parts of the page they can edit (Only the middle section), but allows us to add new content to the top or bottom blocks that will automatically apply to all nodes, regardless on if they're overriden or not.

This leads us to the second problem, how do we add new Sections to the default template and have them flow through to the overridden nodes in the correct place. Again this is a problem in Layout Builder and something that should be considered for XB.

TLDR; Updating overriden content in Layout Builder from the default template is painful. We should take the lessons we've learnt from Layout Builder and apply them to XB from the start.

Here's a link to the Figma design for Content Templates: https://www.figma.com/design/am9E9G2MeDOHnkET2uSRc7/-Feature--Content-Te...

More than happy to answer any design-related questions! 👍

I've just found this from Slack. The video at https://www.drupal.org/project/canvas/issues/3455629#comment-15646756 matches exactly how I imagined this working - structured content interspersed with unstructured content, but still providing the ability to update the global template which applies to all nodes even when the template for that node has been overridden, which is very difficult in Layout Builder right now.

I understand why it's not in v1.0, but does represent a common use case, so v1.1 perhaps ;)