Consider supporting Layout Builder Overrides for other view modes

Should this be active now? I'm guessing the only reason it was postponed was because it was created before the referenced issue was closed.

Anyway, this definitely makes sense to add, from my point of view Layout Builder needs to act like Panalizer: all options can be customised per view mode, along with being opt-in/out per view mode.

I believe I'm agreeing with the general idea for this story and with the comments above.

Our use case: we have a taxonomy vocabulary and want to use Layout Builder for it so that content editors can tweak some of the terms and still use a default for most. The vocabulary is 2 levels deep and we want a default / customizable layout for both levels. Level 1 will have one default layout and Level 2 will have another.

We are thinking of implementing this by adding two view modes and then doing some magic to show one or the other on a given page when it is viewed.

I think there are some current challenges with this:

- I believe https://www.drupal.org/project/drupal/issues/2955065 says that layout builder only stores one customized layout per entity
- Layout builder only provides one tab for `/layout` and the route doesn't seem to care about view mode

I think for now we can assume for our use case that a customized layout will only ever be created for one view mode and that will be used for the page display. We may try to hook into the system and copy over the view mode's default depending on the taxonomy level. That doesn't apply to the broader use case, but I'm not sure how common that is.

I can see a broad issue being:

- Layout builder is used for page and teaser
- Content editor customizes page
- (another issue?) Default layout for teaser is updated

The editor would likely expect
- Their page level customization is maintained
- Their teaser is updated for the default

I'm just starting to dig into this and see what we can do.

Thanks for tackling these difficult problems.

re #4 @AaronMcHale

from my point of view Layout Builder needs to act like Panalizer: all options can be customised per view mode, along with being opt-in/out per view mode.

I talked to @eclipse one of the Panelizer maintainers and he said it is not possible to have Panelizer overrides per view mode.

I don't think we should necessarily support all the features that panels/panelizer supported in Contrib. Panelizer was very complicated, had tons of options and was very hard to learn how to use. The more options we had to Layout Builder the harder it will be to maintain a relatively simple UI.

Also allowing per view mode overrides will make translations much more difficult and especially translations with content moderation.

#2946333: Allow synced Layout override Translations: translating labels and inline blocks is already going to very complex and this will make it even more complex.

Even without translations offering per view mode overrides would make the UX for using Content Moderation and Layout Builder together much more confusing.

We can't have multiple forward revisions so all of the changes to all of the overrides would be saved in the same forward revision. How would some review the changes to all of the overrides when moving the layout through transitions for Content Moderation.

Before Layout Builder we had one entity form so when you moved an entity through Content Moderation transitions you could see all the changes you had in 1 form

Now with layout builder we are effectively introducing another entity form where you can move an entity to another Content Moderation state. So when you use the Layout Builder form to move the entity state you are already using a form where you cannot see all the field values you are transitioning to the new state(because other field values may be changed and not all field values will be displayed on the layout)

If we introduce as many new forms(Layout Builders) as we have View Mode do we allow changing Content Moderation state on all View Mode overrides? In any case if you use layout builder to move the Entity to a new Content Moderation state you would know not only not see some of the field values you would have check the layout override changes for all of your View Modes to really know what the state of the entity is.

Using of additional argument with default value fix the problem with supporting other view modes, and prevent errors after code changes.

Here is patch that fix this problem.

Below is issues with majors bugs that appears because view modes are not supported:
https://www.drupal.org/project/drupal/issues/3008924
https://www.drupal.org/project/field_formatter_class/issues/3053629

Being able to override custom view mode per entity is great. We have a specific use case is that we want to replace the default 'full' canonical view mode with a custom view mode at certain conditions/contexts, we use `hook_entity_view_mode_alter` to achieve that, also, the user wants to be able to override on entity level for that custom view mode use layout builder, but layout builder currently does not seem to support this flow, opened a new issue https://www.drupal.org/project/drupal/issues/3083754 for this.

Is this not already in core? Under each view mode on an entity bundle, i see a checkbox option to enable Layout Builder. But maybe there's more to it that this issue/patch is adding.

Regardless, I arrived at this issue in a search for getting Layout Builder pages indexed and rendered in Search API search results.
It seems like the indexing part is already handled per https://www.drupal.org/project/search_api/issues/3038591 via the `rendered_item` field.

But, I'm still at a loss how to pull in Layout Builder block content/values into the search result templates, and thought this issue may have some overlap with that issue since i'm using a search result view mode on each of my indexed entity bundles.

I can think of 2 possible solutions:
1) Add fields specifically on the node bundle to be used for the search result rendered content
2) Write some code to dig down into the layout builder config on the node and get the values I want to render in the results
3) Maybe this issue would allow for another solution?

Is this not already in core? Under each view mode on an entity bundle, i see a checkbox option to enable Layout Builder. But maybe there's more to it that this issue/patch is adding.

You can enable LB for any entity view display, but you cannot also enable layout overrides for individual entities for all display modes. In other words, you cannot create a different layout for the teaser view mode of node #1 and node #2. You can only do that for the default/full entity view display. You can see this when checking that "Enable layout builder" checkbox, then seeing that the additional checkbox to allow overrides doesn't appear on the other view modes.

patch 39 applies cleanly to head of 9.1.x - triggered tests
patch 39 applies cleanly to head of 9.0.x - triggered tests
patch 39 applies cleanly to 8.9.x

Thanks!

I agree with @bkosborne, this patch doesn't fix the issue. Therefore I have developed this module that implements the functionality described in the issue.

@aarnau thanks for this module, we're using bootstrap and have some issues with the layout builder

I haven't yet reviewed your module but I will.

There's also this one:
https://www.drupal.org/project/bootstrap_layout_builder

haven't reviewed it yet either.

I did have to add this css to my sub theme to fix some css issues.

see related issue:
https://www.drupal.org/project/wxt/issues/3199500

screenshots are provided as well as the css fixes that override core css.

Here is a reroll for D9.3.0-beta2

After #2948828: Layout Builder's Field Blocks do not work with Quick Edit queckedit integration is removed

Quickedit integration even was removed #3264633: Remove \Drupal\layout_builder\QuickEditIntegration and refactor it so that quickedit contrib provides the integration with layout builder

re-rolled

I was trying to test #28 , but on giving the path like /node/5/layout/teaser , I get a page not found error, it will be helpful if we know how the solution is approached and steps to test the issue.
Thanks!

Can anyone explain the difference between this issue and #3008924: Callers of LayoutEntityHelperTrait::getEntitySections() do not account for the view mode? Currently, the proposed changes in both issues are identical.
The last patch here is almost identical to the merge request in #3008924: Callers of LayoutEntityHelperTrait::getEntitySections() do not account for the view mode.

It also seems to me that current patch is incomplete or it the issue description lacks some information about the solution.

We just ran into this and I think it would also make a lot of sense to pass the #view_mode to the layout theme.

Currently, that's not possible, but there are several cases, for example in layout_paragraphs, where you'd need to determine which view mode the current paragraph, which contains the layout (and thereby the layout) is rendered in!

So that in hook_preprocess_layout(&$variables){} we can determine the view mode of the entity the current layout is rendered in:

function hook_preprocess_layout(&$variables) {
  // Allow getting the view mode the current layout is rendered in:
  $view_mode = $variables['view_mode'];
}

Should we have a separate issue for that, or solve it here? I think it's quite close to this issue?