When creating a new layout override for a node, alter core's behavior of cloning the node type's default layout to instead cloning the node's currently selected layout

subscribing

This is really annoying behaviour, Very interested in any suggestions for rectification or a work around

Is there a point in the right direction someone could direct me? This might become of interest to me.

I've started to look into this as I believe it makes the module 100 times more useful to allow overrides of stored layouts. From what I can tell the issues is that the route /node/xxx/layout is defined by, and to use the default or override section storage. So instead of deciding the storage by weight and applies logic, it just picks from those two.

We either need to incorporate that route into the Library section storage so it's pickable (which will likely need some tempstore changes) or look at an alternate method such as just saving the library layout as an override when hitting that route.

I will attempt to get a POC going soon

See #3143635: Change Layout Preparation into an Event to allow proper alterations

This should allow layout library to use an event subscriber to change the layout.

Simple POC: requires patch from #3143635: Change Layout Preparation into an Event to allow proper alterations

+++ b/src/EventSubscriber/PrepareLayout.php
@@ -0,0 +1,77 @@
+    $events[LayoutBuilderEvents::PREPARE_LAYOUT] = ['onPrepareLayout', 10];

I think this value needs to be higher than 10, otherwise, the LB event subscriber runs first.

Correct, when I wrote that, the other patch had a lower priority, once that gets into core I will rewrite this one

Now that the parent is in RTBC, here is a patch to react per comments on #9/#10

Not quite sure how to get this in with tests since the core change is only as of 9.1... anyways, here's a patch that proves it with the test for d9.1. For d8 either I guess just apply both patches?

Ok, trying this again with the test checking for the new class in core, this should pass D8 on both accounts, and only D9 when full patch is applied.

Forgot to wrap around the subscribed event as well

Hi, I've tried to apply the patch, but when I create a node with a layout I've the following error twice:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'd76bcca1-8435-48a2-8ba0-8f06b3d724d3' for key 'block_content_field__uuid__value': INSERT INTO {block_content} ("revision_id", "type", "uuid", "langcode") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => [:db_insert_placeholder_1] => basic [:db_insert_placeholder_2] => d76bcca1-8435-48a2-8ba0-8f06b3d724d3 [:db_insert_placeholder_3] => it ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (linea 810 di /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

UPDATE: I've applied the patch AFTER creating the layout.
Now I've delete and re-created the layout. Now, if i select the layout on the node, the layout is ignored. Before the patch the node was rendered with the layout from the library.

UPDATE 2: I'm using D9.0, not 9.1. If I apply the patch from https://www.drupal.org/project/drupal/issues/3143635 I've a wsod, probably because I'm also using Layout Builder Asymmetric Translation and other modules?

FiNeX - I think that the patch you are applying from https://www.drupal.org/project/drupal/issues/3143635 doesn't apply cleanly for < D9.1. If you do a diff after applying the patch, one of the class files ends up being cutoff and the WSOD occurs because the syntax of that file is broken.

@pyrello: indeed, I've seen that after patching. I've to try to manual apply the patch hoping that it will be compatible. I will try tomorrow :-)

I've applied the path from #17 and followed these steps:

- Enable " Allow each content item to have its layout customized." and "Allow content editors to use stored layouts" for the node type.
- Create a node and select a layout that has been added to the library.
- Verify that the node has the layout (check)
- Go to the layout override page (node/*/layout)
- Verify that the layout to override is equal to the layout selected for the node (fail)

On the layout override page I do not see the layout as selected in the node, I am still seeing the layout as defined in the default layout for that node type.

Am I missing something or is the patch not working?

I've just tested again with no issue, this might help clear things up:

Drupal 8.x -> 9.0:
- Requires patch from (I believe if on D8.x you need patch #26): #3143635: Change Layout Preparation into an Event to allow proper alterations

Drupal: 9.1:
- Core patch is already applied

You should also test without other layout-altering modules enabled.

Allright, I've managed to apply the core patch from #3143635 (which was a bit of a hassle, because I had other patches affecting layout builder so this one didn't apply properly)

After applying the core patch and the patch from #17 in this issue I retested the steps I described in #21, this time succeeding on all steps.

I can hereby confirm RTBC for #17 (based on Drupal 8.8.11)

Committed and pushed. Thanks for all the work on this!

Thank you, for working on a fix for this issue.
Using patch #17 at this time.

Waiting for a new release. Soon I hope.

Waiting for a new release. Soon I hope.

I think that fix is already released.

Ivan, Have you had a look at the following

tim.plunkett committed 4c9dcce on 8.x-1.x authored by b_sharpe

January 15, 2021 22:19
2 months ago

Layout Builder Library 8.x-1.0-beta2 was released 20 February 2020

The patch still apply on 8.x-1.0-beta2

I think until #3075067: Duplicate entry for key 'block_content_field__uuid__value' is committed, a release might cause more harm than good.

@RajabNatshah, never mind I missed the year in the release date...

Noted;
Thank you Bryan for the note about #3075067: Duplicate entry for key 'block_content_field__uuid__value'