Introduce field type that renders arbitrary elements in a selectable layout

Updated the patch for coding standards fixes
Renamed a couple things for clarity
Added rudimentary coverage of the formatter

composer.json and hook_help are required.

In the interdiff:
CS fixes for previous fix
Add support for context-aware blocks
Not in the interdiff:
Removed TestContentBlock since TestBlockInstantiation works just fine

1. +++ b/core/modules/layout_builder/layout_builder.module
   @@ -0,0 +1,19 @@
   +      $output .= '<p>' . t('Layout Builder provides layout building utility, surprisingly.') . '</p>';
   

   Yes hook_help is a bit of a white elephant, but not sure folks will appreciate this self-deprecating humour.

2. +++ b/core/modules/layout_builder/src/Plugin/Field/FieldFormatter/LayoutSectionFormatter.php
   @@ -0,0 +1,166 @@
   +      foreach ($blocks as $uuid => $configuration) {
   +        /** @var \Drupal\Core\Block\BlockPluginInterface $block */
   +        $block = $this->blockManager->createInstance($configuration['plugin_id'], $configuration);
   +        if ($block instanceof ContextAwarePluginInterface) {
   +          $contexts = $this->contextRepository->getRuntimeContexts(array_values($block->getContextMapping()));
   +          $this->contextHandler->applyContextMapping($block, $contexts);
   +        }
   +        $access = $block->access($this->account, TRUE);
   +        if ($access->isAllowed()) {
   +          $regions[$region][$uuid] = $block->build();
   +        }
   

   this looks generic and useful enough to be somewhere else? Putting blocks into regions, applying context and checking access. I'm assuming we do the same thing in multiple places. And I'm not sure its the domain of a formatter to have all that knowledge, should defer to something else.

3. +++ b/core/modules/layout_builder/src/Plugin/Field/FieldType/LayoutSectionItem.php
   @@ -0,0 +1,87 @@
   +    $properties[static::mainPropertyName()] = MapDataDefinition::create('map')
   +      ->setLabel(new TranslatableMarkup('Layout Section'))
   +      ->setRequired(FALSE);
   

   eww serialized data. This means we *cannot* support updating this over REST (unserializing user provided content is a security hole). We need to make sure that we have a normalizer that explicitly filters this out.

4. +++ b/core/modules/layout_builder/tests/src/Kernel/LayoutSectionFormatterTest.php
   @@ -0,0 +1,212 @@
   +  public function providerTestLayoutSectionFormatter() {
   

   there are no tests here that cover the access check (but again I think that logic belongs somewhere else outside a formatter, and hence should be tested outside the formatter too).

First up! We're moving this work to a core sandbox https://www.drupal.org/sandbox/timplunkett/2874553
It's not really ready for review yet, and this will become an epic and terrible thread if we keep posting every patch here.

To address #8 directly

1) Yes. Just wanted to get the failure out of the way for the time being

2) Absolutely. Page Manager, Panels, and Block all have their own versions of this, but with other domain-specific bits sprinkled in. This absolutely needs to be a stand-alone thing.

3) I defer to @EclipseGc on this, it was his idea

4) Also true.

Only PHP is the issue, so json and yaml are fine

Sweet!

I see this doesn't depend directly on field_layout; how will they interact?

"Per-entity overrides" was a "Could" have on the roadmap of #2795833: [plan] Add layouts to entity displays (both form and view). It sounds like feedback at DrupalCon indicated this feature was essential enough to reprioritize the roadmap?

I'm a little concerned about the experimental module proliferation, also. It would be good to see other parts of the layout initiative become stable before we add additional features.

Sorry for the long delay, as mentioned in the other issue I got hit pretty hard with Drupalflu and am just prairie-dogging back into the world of the living.

Aside from experimental/architectural considerations, one thing I want to bring up is concern about the nomenclature. Right now it's called a "Section" field and I think we run a serious risk of confusing users who are adjusting to Drupal's naming conventions, as well as needlessly obscuring the nature of the field type. Why not name it a "Layout" field, since that's what it explicitly is? That preserves "section" as yet another abstract noun in our dwindling strategic reserve, and (I think) makes the field type's intended use case more transparent. It also makes the connection between "layouts" (when mentioned in contrib, documentation, etc) and the options that appear in the field's configuration, less mystery-meat.

Finally, are that any objections to tightening up the title of the issue to: "Introduce field type that renders arbitrary elements in a selectable layout"? The current title crosses over into the domain of "Field Layouts" and per-entity field layout overrides, which should definitely remain a different beast architecturally (IMO).

Also, as a point of philosophy: I'd be REALLY worried if this feature made it into a core release but Field Layouts didn't; if it's the only option in core for layout control, people will use the hammer they have, and we'll quickly encounter a generation of sites composed of nothing but layout fields — a structured content nightmare, for all their usefulness.

This field is a godsend for the edge cases that Field Layouts wouldn't help — one-off landing pages composed mostly of blocks and other bits that really only appear on that particular page, ever. For cases where users just want more layout and positioning control over otherwise (fairly) structured content, plopping a layout field in there would kill any hope of decoupling, or heck, generating a meaningful RSS feed.

If it helps: yes please, lets use the words that go with the concept and go with "layout field". No need to inject a new term that creates more dots for people to connect in their mental model of things.

Well said.

Can we get some screens?

Or even some conceptual diagrams of what's the goal here. Is this about (eventually) implementing the "layout blocks" UI concepts @dyannenova designed?

Also: slightly amused by the decision to *leave open* the possibility to bikeshed the naming of things ;-P

Changing to NW per #9 to avoid pre-bikesheding.

Thanks for the update!