Problem/Motivation

Currently if a Entity is individually overriden and customised using Layout Builder, it is at risk of becoming completely out of sync with the default layout of the Entity Type/Bundle as a whole.

Later in time if one decides to change the layout of the Entity Type/Bundle from the Manage Display Layout Builder UI, the changes don't reflect to the individually overriden Entities. This is not an issue if there is only a couple of landing pages, but a huge maintainability issue if Layout Builder is used for something like articles which have sidebars and when something in the sidebar needs to change.

Proposed resolution

One way out of this problem could be to have some Sections of the Layout be locked and not available for editing when the individual Entities being customised. For example have the option to lock the sidebar Section and only have the middle content section be available for editing.

Remaining tasks

Determine best approach and whether this is best suited for Contrib or Core.

User interface changes

API changes

Data model changes

Release notes snippet

Comments

mikey en created an issue. See original summary.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

Well, even if you locked down certain sections in a layout, what if you decide to change the entire default layout (and thus section placement)? that section that you locked down and the section you allowed to be overwritten by individual nodes may no longer exist. I don't see how you could possibly merge those changes gracefully for each overridden node.

Why not just disable overrides for content types where you may alter the layout? What's the use case for allowing layout overrides for individual nodes for that content type?

mikey en’s picture

mikey en commented

@bkosborne
The main idea behind this feature request is to have a section which is always same for all the nodes in that content type, whether its overridden or not. I think the main Idea behind content types is to have some level of coherency for the nodes among other things. Having a section locked down for the content type as a whole and which is same across all the nodes under that content type will help achieve that IMHO.

"What's the use case for allowing layout overrides for individual nodes for that content type?"
Lets say we have a sidebar section which designed in the layout builder, things change and lets say we need to change something for the sidebar for all the nodes of the content type. For that to happen in the current scheme of things we would need to change it for the content type in the manage display page and also for all the overridden pages as well, that to me looks like a lot of work if u have huge amount of overridden nodes. This is what i felt hard to do and had to resolve it in the theme templating.

The fact that the overridden node has no sense of belonging to any thing and is completely in itself works for a lot of use cases and likewise there will be use cases where its not needed at all.But if its used for the main articles nodes for a site I feel people need this lock down flexibility. This is just a use case, pretty sure people will come up with many if this option is provided :)

johnwebdev’s picture

johnwebdev commented

Wouldn't this feature be something that Page Manager could help you do, if it supported Layout Builder?

mikey en’s picture

mikey en commented

@johndevman , cant say about that. I started with Drupal8 + display suite.

aaronmchale’s picture

aaronmchale
Primary language English
Location Edinburgh, Scotland
commented
Title: Individually customised nodes in the layout builder are completely out of sync to the overall layout of the content type » Individually customised Entities in Layout Builder are at risk of becoming completely out of sync with the default layout of the Entity Type/Bundle
Issue summary: View changes

This is an interesting issue, although I'm not sure which side I fall on, I could see why one would want this, but also why this might not be appropriate.

Another option is to initially develop this idea as a Contrib Module once #2942661: Sections should have third-party settings is in, since Sections having Third Party Settings could make this a lot easier to do in Contrib.

Also updated the IS and title as this is not a Node specific problem and applies to all Entities that use Layout Builder.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Title: Individually customised Entities in Layout Builder are at risk of becoming completely out of sync with the default layout of the Entity Type/Bundle » Devise a locking/inheritance mechanism for overrides to mitigate when they become out of sync with the default layout
Issue tags: +Blocks-Layouts

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

pyrello’s picture

pyrello commented
Related issues: +#3171452: Allow reseting of individual Layout Builder sections to default

Just adding an issue I closed early as related to this. I think this is a much more difficult problem to solve than is obvious based on using Layout Builder. Even once #3208766: Add UUID to sections gets done, it would be necessary to start tracking the original UUID that was overridden in addition to having one for the section that is replacing it. There is currently no way to replace a given section layout with another, so when that is necessary people will just create a new section with the correct layout and move blocks into it or recreate them. At that point, there is no way to track the new sections association with anything in the original section layout.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.