Add proper context-awareness to Layout Builder

Here it is built on top of #2922033: Use the Layout Builder for EntityViewDisplays

Here's a patch NOT built on all the other changes, since this is actually important now that FieldBlock is in.
Writing a test now.

Uh whoops

Fixes the above fail, and adds tests of its own.

Here's a version that is dependent on #2927349: Decouple the Layout Builder UI from entities going in. Marking NW for now so as to not trigger the testbot.

Blocker is in!

+++ b/core/modules/layout_builder/layout_builder.module
@@ -166,9 +169,11 @@ function layout_builder_add_layout_section_field($entity_type_id, $bundle, $fiel
+    $contexts += _layout_builder_get_contexts_for_entity($entity);

@@ -187,3 +192,22 @@ function layout_builder_entity_view_alter(array &$build, EntityInterface $entity
+function _layout_builder_get_contexts_for_entity(EntityInterface $entity) {

Any reason not to implement ContextProviderInterface here and add a new tagged service.

e.g. see NodeRouteContext etc

https://gist.github.com/larowlan/dc88c7e2cd2d816fe80d99a8c92160b3 was something I'd used before

+++ b/core/modules/layout_builder/layout_builder.module
@@ -187,3 +192,22 @@ function layout_builder_entity_view_alter(array &$build, EntityInterface $entity
+  $definition = new ContextDefinition("entity:{$entity->getEntityTypeId()}", new TranslatableMarkup('Current @entity', [
+    '@entity' => $entity->getEntityType()->getSingularLabel(),
+  ]));
+  return ['layout_builder.entity' => new Context($definition, $entity)];

I think if we plan to remove this after #2932462: Add EntityContextDefinition for the 80% use case, we should avoid adding it in the first place.

It's a couple of lines - we could just inline it.

Then when we have ECD, we can simplify it.

Implementations of ContextProviderInterface rely on global state or preconfigured information.
We can rely on neither.

Imagine a view of nodes, each laid out with Sections.
When rendering each node, the context must be derived from that entity at that time. There's nothing in the routeMatch to help us there.

Inlined _layout_builder_get_contexts_for_entity()

Looks good to me. 👍

Actually, the suggestion was from @dead_arm, she deserves the credit there :)
Here's the after screenshot, before it said "Current user" twice

Adding @dead_arm to issue credit. :)

I manually tested this.

Steps taken

1. enable module
2. enable for basic page node type
3. add a node
4. edit layout
5. add body field
6. attempt to edit body field
7. fatal error in ajax response

AjaxError: 
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /layout_builder/update/block/overrides/node%3A1/0/content/e94baa5f-2a30-463a-9485-d45f1dfd98d2?destination=node/1/layout
StatusText: 500 Service unavailable (with message)
ResponseText: The website encountered an unexpected error. Please try again later.Drupal\Component\Plugin\Exception\ContextException: Required contexts without a value: entity. in Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping() (line 96 of core/lib/Drupal/Core/Plugin/Context/ContextHandler.php). Drupal\layout_builder\SectionComponent->getPlugin() (Line: 46)
Drupal\layout_builder\Form\UpdateBlockForm->buildForm(Array, Object, Object, '0', 'content', 'e94baa5f-2a30-463a-9485-d45f1dfd98d2', Array)
call_user_func_array(Array, Array) (Line: 514)
Drupal\Core\Form\FormBuilder->retrieveForm('layout_builder_update_block', Object) (Line: 271)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 153)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 657)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Test site -> https://due6v.ply.st/node/1/layout

If we don't have any contexts passed, we shouldn't run them through the ContextHandler.
Simple fix, really nasty side effects without it.

Ideally we'd have tests here, but we're blocked on #2924201: Resolve random failure in LayoutBuilderTest so that it can be added to HEAD, which is already tagged as a beta blocker

😩

Ok, Tim walked me through this patch, as well as demoing the before/after behaviour. We hit a snag at one point with some PHP errors, but tracked it down to applying the patch mid-demo and some old cruft that was exhibiting the bugs this patch is fixing leaking into the new stuff. Upon clearing that out and starting over, the patch worked great.

It's really nice that this patch limits the number of options available to people to stick in their layouts to only those that are relevant. Huge +1 to that from a UX POV.

The code itself is really straight-forward. There's one bit of ugliness which is some manual string concatenation ickiness in a couple of places, but there's a follow-up to make a nice API method for that at #2932462: Add EntityContextDefinition for the 80% use case. There's a method that gets removed, and a couple of others that get their signatures adjusted for new (optional) parameters, but all of these are limited to the layout builder module itself, not anywhere else in core. Additionally, there's test coverage for the new behaviour.

So, in sum: no complaints here! :)

Committed and pushed to 8.5.x. Thanks!

Stupid freaking PHP 5.
Thanks PHP 7 for fixing this asinine rule for traits.

Ok, take two. :)

Committed and pushed to 8.6.x (oooh!) and cherry-picked to 8.5.x.

Hi, looks like whatever was done here, was undone without much explanation in later commits. How could I pass the current entity to a Views block placed using Layout Builder?

Yes I've got the same problem, I have a contextual filter and when I add the views block to the layout builder, I do not see the option to choose the contextual parameter. Any pointers to help ?

Same problem for me as unknownguy. I suspect this is not really what this issue was about, but could we look to https://www.drupal.org/project/viewsreference as an example of how to provide an Argument form field which a user could use to enter arguments that are passed to the view?

Same here, I've been trying different combinations but I'm still not able to 'expose' contextual filters when including views (block displays) using Layout Builder, any hint on this?

Hey @eworwa I was able to pass arguments to a view block via a field in Layout Builder by applying this patch to ctools:

https://www.drupal.org/project/ctools/issues/2759445

Pay attention to comment #55. You have to do a tiny amount of configuring within the view itself for the field to appear.

Good luck!

Contexts _without_ data not visible in block context selector.
I created https://www.drupal.org/project/drupal/issues/3194198