#validation

I feel like we are talking past each other with different use cases and scenarios and concerns that are not being impacted by Experience Builder. My understanding is that there are two primary ways of configuring Search API: text based search and faceted search (as well as combination of the two).

When using text based search and the intent is to index the whole page, the "Rendered HTML output" with the default content type template (same as what user would see when navigating to the page) should be used. Search API would allow configuring other view modes to be used for indexing but those wouldn't include the content added to the slots, but only content that is being rendered through those view modes. So long as we keep view modes working, this should all work without specifically having to accommodate them. This is the same experience that you would get when using Layout Builder today.

When using the text based search, the results would often display an excerpt which is generated based on what is in the index. This allows highlighting the text that is being matched. This shouldn't require any special accommodations from XB so long as what is stored in the index is sensible.

When implementing a faceted search, it's common to configure the results to display to using a view mode like cards or search result. In this scenario, text is not being highlighted. Even in this scenario, the index may include the full rendered page, highlighting that the index is a separate concern from the presentation of the results.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Added the changes from the parent, lets get some working tests.

Cherry picked the change, we need to make tests.

Fun fact is that indexes have a default, like value => [value], but that the shape can be defined in the childs, therefor this is really hard to reallt validate.

#17: that's not matching what you said earlier → .

Unless you meant that that would be the initial state, and you intend to only use the default content type template for search indexing and a different content type template for presenting search results?

But if we do that, then it follows that the information that was matched is absent from the search result's presentation, meaning highlighting is impossible.

@lauriii that's the opposite of what this says in #7:

Last but not least: per @lauriii, there won't be a "search" or "search index" view mode for XB — search must be configured to use the "default" view mode's representation of content entities both for 1) crafting a search index to power the search, 2) presenting search results.

is there a miscommunication somewhere?

If search results use a view mode for rendering (which a lot of sites do), then it shouldn't require any special handling in XB, it just needs to not break using view modes for rendering.

The place where it might get tricky is 'results snippet' type situations where the search result is trying to show the searched keywords in the context of the results. I'm not sure how that's generally implemented in search API or not or whether it would need special handling. For me that's the least important aspect to worry about - it's the initial indexing that feels unresolved still.

Rendering Search results in the same way as the content's detail page doe not seem like the most commonly chosen way of configuring it. I did a quick poll at the contribution room at Drupal Mountain Camp, and everyone who answered me always configures some kind of teaser, card or search-result view mode when rendering a search result page.

We should definitely support configuring customizing how content is displayed in the search results page. I'm not sure we need to do that in this issue though because it might make sense to design and implement solution specifically for that, because it's such a common use case.

When needing complete control over what all is indexed, it should be indexed using fields, because then it's possible to boost per-field. It gives a lot more control.

This however would mean something like https://www.drupal.org/project/layoutbuilder_search_api → for all components/props

I think that 📌 Refactor the XB field type to be multi-valued, to de-jsonify the tree, and to reference the field_union type of the prop values Active would also handle this - because the props would be available as field data to search API then without an additional translation layer.

Last but not least: per @lauriii, there won't be a "search" or "search index" view mode for XB — search must be configured to use the "default" view mode's representation of content entities both for 1) crafting a search index to power the search, 2) presenting search results. Related: 🌱 [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters Active and 📌 Create a configurable search api processor for XB data Active

It's not clear to me yet how that avoids the

but without elements that would 'pollute' the search results like field labels, related content blocks, CTAs, social widgets etc. so that if I search for "newsletter" or "Facebook" I don't get every article on the site back in the results, but only the ones with content actually mentioning newsletters or Facebook.

problem described in 🌱 [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters Active though.

Rendering Search results in the same way as the content's detail page doe not seem like the most commonly chosen way of configuring it. I did a quick poll at the contribution room at Drupal Mountain Camp, and everyone who answered me always configures some kind of teaser, card or search-result view mode when rendering a search result page.

For the indexation part, I also don't see a way that would remove those pollutions without having a seperate view mode, but I personally think that's not as bad. When needing complete control over what all is indexed, it should be indexed using fields, because then it's possible to boost per-field. It gives a lot more control.

This however would mean something like https://www.drupal.org/project/layoutbuilder_search_api → for all components/props, which is another approach that could be taken. This removes the double rendering that catch talked about in #13.

This is not actionable until decisions are made with solid answers WRT the concerns I surfaced.

This blocks pretty much everything in 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active .

In more concrete terms, it blocks 📌 Prevent fields from being deleted if they are used in Experience Builder field's dynamic prop values Active .

updated the CR to be a bit easier.

The IS should explain the consequences of this bug more clearly. For instance, top-level constraints are not validated with this method:

$violations = ConfigEntityAdapter::createFromEntity($config_entity)->validate();

Also, the CR needs some editing for style. It should explain what is new, and how it has changed. The chatty style isn't appropriate.

Last but not least: per @lauriii, there won't be a "search" or "search index" view mode for XB — search must be configured to use the "default" view mode's representation of content entities both for 1) crafting a search index to power the search,

afaict this is incompatible with 📌 Create a configurable search api processor for XB data Active - which is suggesting not rendering XB at all when configuring search indexing, except via the special search API processor. I'm not convinced by that issue yet (and left a question on there which hasn't been answered yet) but has that been abandoned or is this a mistake? Using 📌 Create a configurable search api processor for XB data Active would mean either not using a view mode at all in search indexing, or a view mode minus XB data that only shows entity fields, with the XB data then provided by the separate processor.

If you had to use the default view mode and the processor it would mean double-rendering when search indexing.

2) presenting search results.

This seems unnecessarily restrictive and also unenforceable. e.g. you can configure search API views to return results from a search index, then use any view mode on the entity that you like right now - like displaying search results as a grid of cards or whatever.

#10:
RE: your question: per discussion this morning with @lauriii: as the Site Builder modifying/creating an XB Content Type Template, you have complete freedom to completely change your mind about adding/removing exposed Content Type Slots. So the answer is: "yes, you can revert".

1. ✅ Sorry 🙈 This has changed — see #7.2. Issue summary updated in #11 👍
2. I suspect we are on the same page, but … I disagree with your specific wording 😇 I know I'm gonna sound super nitpicky, but all of this is going to have enormous consequences for UX and data integrity, so I went to be painfully precise 🤓 😜
   • It should not be "any slot", because slots can live within other slots.
   • Furthermore, I'm not convinced yet that only slots must be exposable as a Content Type Slot, but any component instance. That way:
     • if it's a component instance without slots, it means you can modify this component instance's inputs — for example: XB's my-section SDC would then be able to have inputs (image, text next to the image) that are defined in the Content Type Template, but if the Content Creator chooses, they could modify the inputs without the ability to add more component instances
     • if it's a component instance with >=1 slot(s), it means the Content Creator can modify as much as they like: remove the entire component tree in one of those slots, keep it empty, replace it with other component instances, or keep it all the same as in the Content Type Template
3. ✅ This has been answered by @lauriii. Issue summary updated in #11 👍
4. 👍 WFM! But would there then be affordances to ensure the Site Builder is explicitly aware of which fields (whose values) are not (yet) being presented?
5. ✅ This has been answered by @lauriii. Issue summary updated in #11 👍
6. 👍 This ties well into what @lauriii has confirmed Product-wise — see the updated information for Question 2 in the issue summary.
7. 🤔 I'm not sure how to interpret this. Are you saying that a Site Builder should or should not be able to expose a Content Type Slot that contains some component instances populated with structured data?
8. 👍
9. ✅ Sorry 🙈 This has changed — see #7.1. Issue summary updated in #11 👍
   (And no, that's not what I meant: I was referring to disallowing deleting Content Type Slots, but @lauriii has since said this is fine, and it's fine to lose Content Creator-crafted data.)

I see that I failed to update the issue summary with @lauriii's input from #7. Now updated. Some questions are fully answered, some are merged.

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?

wim leers → credited lauriii → .

Reflected #7 in the PoC MR: https://git.drupalcode.org/project/experience_builder/-/merge_requests/7....

Based on discussing 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active with @lauriii this morning, a few things surfaced:

1. Supporting multiple view modes MUST be supported from the start. But, only the default view mode will be customizable per entity. So, a teaser view mode for example would look the same for all entities of that content entity type+bundle: the same exact XB component tree would be used for all (i.e. the one in the "teaser" Content Type Template config entity), while of course resolving the structured data mapped into the component tree (i.e. using DynamicPropSources).

   This avoids the entire "keep Content Type Slots in sync across all Content Type Templates (one per view mode) for this content entity type+bundle" problem. 👍

2. XB is used for either all or none of the view modes. IOW: as soon as you chose to use XB, all existing EntityViewDisplays are ignored. Those that don't have an XB Content Type Template defined yet render nothing.

   Note: this will change in the far future per @lauriii: he intends to allow specifying an XB element (see 📌 Clarify "components" vs "elements" vs "patterns" Active ) to be associated with each field type, which essentially becomes the XB equivalent of "the default formatter".

3. Last but not least: per @lauriii, there won't be a "search" or "search index" view mode for XB — search must be configured to use the "default" view mode's representation of content entities both for 1) crafting a search index to power the search, 2) presenting search results. Related: 🌱 [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters Active and 📌 Create a configurable search api processor for XB data Active .

   It's not clear to me yet how that avoids the

   but without elements that would 'pollute' the search results like field labels, related content blocks, CTAs, social widgets etc. so that if I search for "newsletter" or "Facebook" I don't get every article on the site back in the results, but only the ones with content actually mentioning newsletters or Facebook.

   problem described in 🌱 [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters Active , though.