Themes have no context of the entity being rendered in preprocessing a layout when using Layout builder

Seems like an oversight. Thank you for figuring out a way to add this.

+++ b/core/modules/layout_builder/src/Section.php
@@ -88,6 +88,9 @@ public function toRenderArray(array $contexts = [], $in_preview = FALSE) {
+    if (isset($contexts['layout_builder.entity']) && $entity = $contexts['layout_builder.entity']->getContextValue()) {

Please add () around $entity = $contexts['layout_builder.entity']->getContextValue()

can I ask why?

Because it always trips me.

its not needed if its the last statement

Yeah, that's true.

#4
Definitely not an oversight, as layouts themselves have nothing to do with entities. When Layout Builder is involved, sure, there is an entity.

That said, I think this is a worthwhile addition.
(Though that was a reeeeallly fast RTBC...)

However, see #3018782: Remove extraneous context mapping of layout_builder.entity. That context key is hopefully not long for this world...

Also, I don't think that patch is going to pass as-is.
Here's my approach that I was working on before #2 was posted

This currently tests one of four cases.
Overrides, View
Overrides, Layout UI
Defaults, View
Defaults, Layout UI

Previous patch would have broken on a couple of them. Here's an iteration. Didn't get to the tests, too late here.

#8 seems to be working for me on 8.7.10

If we add in the #entity when the whole thing is empty, other stuff (like Quick Edit) will break.

Still needs tests.

I enabled quickedit to test the latest patch. I still receive the following error in console:

Error: Quick Edit could not associate the rendered entity field markup (with [data-quickedit-field-id="block_content/1/field_block_text_text/en/full"]) with the corresponding rendered entity markup: no parent DOM node found with [data-quickedit-entity-id="block_content/1"]. This is typically caused by the theme's template for this entity type forgetting to print the attributes.

The error in #16 is caused by #3072231: Custom blocks break layout builder module - Quick Edit could not associate the rendered entity field markup

I can confirm that the referenced issue fixed the Quick Edit issue. Thanks!

Thanks for confirming @nicxvan!
NW for test coverage

To be clear about #8, the assertion added to LayoutBuilderTest::testLayoutBuilderUi() is testing that this works when viewing a node that does not have an overridden layout.

Within that same method, three other similar assertions should be added:

1. Editing the default layout
2. Viewing a node after an override is created
3. Editing the overridden layout.

In the meantime, here's a reroll of the patch from #15, pushed up as a branch.

Adding a patch because we need this to be able to update to 9.2.x. I tried to create an interdiff but was having issues with that.

Should have changed the target branch before rebasing, sorry for the noise. Minor conflict with #3027653: Allow block and layout plugins to determine if they are being previewed, but straightforward resolution.

Posted a question on the MR about the algorithm used for finding the context

It would be also nice to have a change record for the new API 😇

Draft CR : https://www.drupal.org/node/3278487 (first time so apologies in advance)

Patch from #29 no longer applies for us. Generated patch from MR so we can update drupal core

hiding patches

Rebased the MR, it's still against 9.4.x but should be okay for both

Now updated for 9.5.x

Here is a static patch so a client can test it.

We've been using this patch for over 2 years and just retested the latest, moving to RTBC.

I'd like to see this get merged in as well. I've just tested this on my environment and everything is working correctly.

Random fail on the patch. The MR is still passing. Note you don't have to upload a file, you can append .patch to MR paths: https://git.drupalcode.org/project/drupal/-/merge_requests/608.patch

I always generate a patch file to use in composer, if you use the .patch method any changes to the MR will automatically be pulled in which could allow an untested / unreviewed commit to be pulled into a project.

Committed and pushed 3f9bc84fe6 to 10.1.x and 3be2eba61d to 10.0.x and 921f2563e6 to 9.5.x. Thanks!

Thank you for committing this, it's been indespensible for one of my client's site.

@alexpott I'd like to know if there was more I could have done to help on this issue in order to be credited for the work. I've been attempting to understand the core credit guidelines more closely https://www.drupal.org/core/maintainers/issue-credit I understand that comments like #14 do not qualify for credit, but I thought the interaction in #16-#18 and #45 would qualify.

I've been thinking about how to improve my contributions when it's not directly code related since it's been a topic on the show recently so any feedback you could provide would be highly appreciated.

For the record I understand it takes a lot of effort to review a years old ticket and determine who should be credited and I am not trying to add to that burden but I was talking with @hestenet on one of the recent episodes about credit and he suggested I ask as long as it's respectful, so I hope that's ok.

Hi @nicxvan, thank you for your contributions on this issue. Here are my thoughts about credit and your comments. re #16 and #18 I thought that these were good comments but did not materially affect the patch so I didn't tick the box for them. Similar to #45 - yes that's useful information but in an of itself I don't think that that is a reason to get credit. So I concur that your participation on the issue has had value, I'm just not sure it worth credit.

Here are some examples of things that have a material affect on the patch and the issue:

• Finding edge cases with the solution or improvements to it
• A comment that displays that you've considered all aspects of the problem and the shown how the solution an improvement and will not cause unexpected issues once committed.

@alexpott Thanks! That's super helpful, I think one of the things I was doing here was comparing to the list of things that will not get credit rather than comparing more closely to the list of things that will receive credit and comparing there. It's a slight change but when I change that perspective it's clearer to me how to use that guide. I also appreciate you calling out that the comments had value but didn't rise to credit level, that was definitely one of the primary points of discussion I've been thinking of for the last few weeks.