Allow blocks to be added to entity displays in Field UI

Thanks Tim! Obviously a huge win for sitebuilders here. Goodbye to a whole class of clunky contrib modules to achieve a very common use case.

Awesome. Tested it and works like a charm!

Only quickly scanned the code, looks fine to me.

+++ b/core/modules/field_ui/src/Form/EntityViewDisplayEditForm.php
@@ -83,6 +94,242 @@ protected function buildExtraFieldRow($field_id, $extra_field) {
+      // the new settings fro the next rebuild.

nitpick: missing 'm' in fro

Don't want to set it to needs work for now for missing things (e.g. config dependencies, post update hook to update entity displays) so more people can look at it.

Just some quick comments ...

1. +++ b/core/lib/Drupal/Core/Entity/Display/EntityViewDisplayInterface.php
   @@ -46,4 +46,45 @@ public function build(FieldableEntityInterface $entity);
   +   * @return array|null
   +   *   The array of display options, keyed by block name.
   ...
   +   *
   +   * @return \Drupal\Core\Block\BlockPluginInterface
   +   *   The instantiated block plugin.
   +   */
   +  public function getBlock($name);
   

   These methods names are weird ... given that one returns an object and the other one an array of configuration.

2. +++ b/core/lib/Drupal/Core/Entity/Entity/EntityViewDisplay.php
   @@ -263,6 +308,23 @@ public function buildMultiple(array $entities) {
   +
   +        if ($block instanceof ContextAwarePluginInterface) {
   +          $contexts = \Drupal::service('context.repository')->getRuntimeContexts($block->getContextMapping());
   +          \Drupal::service('context.handler')->applyContextMapping($block, $contexts);
   +        }
   

   I'm wondering whether we could pass in the current rendered entity as context. With that we would have to rely less on block runtime contexts

This is great, but as a sitebuilder I would prefer a solution described here, as it has a number of advantages:
- It offers a clean workaround for the problem that the title is not a field.
- It allows for fields to be placed in any of the theme's regions. This would be extremely valuable, and would allow much more flexibilty than this solution offers.

#7 no reason not to have both? They're not way duplicates AFAIK.

It may not conflict technically, but they do overlap functionally. Both systems could be used to place blocks in between fields.

Energy to work on Drupal may not be infinite. If energy could be redirected, then I propose to redirect it towards the solution that solves more problems (title does not behave like a field) and offers greater flexibility (mix blocks and fields into any region).

This solution, while wonderful in its own right, could lead to lethargy and slowdown in the development of a solution that I believe would be better, and also covers this use case.

Ok, sorry.

What? :D

What is a block field?

Totally love this idea :)

This should fix the failing test.

OK thats a new failing test, but I've just run it locally and it passes... random failure?

@tim.plunkett

What do you mean config dependencies?

Nevermind that one, completely wrong in my mind :)

@tim.plunkett actually, I do remember again re: (config) dependencies. If you add a block in the entity display, a dependency should be added (module I guess) depending on the module that provides that plugin ? Probably in EntityDisplayBase::calculateDependencies ?

I am going to remove the "Needs usability review" tag.

This looks like a fine direction. I am a bit worried that with "Add block field" we leave out the ability to add "non-block" fields, and that no one knows what a "block" field is. But thats purely a labeling thing.

For the form itself, can you add screenshot of various block configs and how they look embedded in the table?

The patch #26 works great. My question is: Can we display the block title as the field label if "Display title" enabled in block setting?

Some blocks can't be placed - main content, site branding

Makes sense to have separate issue to discus UX visibility conditions for blocks

@tim.plunkett btw maybe do abstraction in #1875974: Abstract 'component type' specific code out of EntityDisplay

1. +++ b/core/lib/Drupal/Core/Entity/Display/EntityViewDisplayInterface.php
   @@ -46,4 +46,45 @@ public function build(FieldableEntityInterface $entity);
   +  public function getBlockComponents();
   ...
   +  public function getBlock($name);
   ...
   +  public function removeBlock($name);
   ...
   +  public function setBlockComponent($name, array $block_info);
   

   They looks like duplicate of "components"

2. +++ b/core/lib/Drupal/Core/Entity/Entity/EntityViewDisplay.php
   @@ -263,9 +308,26 @@ public function buildMultiple(array $entities) {
   -      foreach ($this->getComponents() as $name => $options) {
   +      foreach ($this->getComponents() + $this->getBlockComponents() as $name => $options) {
   

   basically components needs derivative types - fields, sections, blocks, extra fields

Following up the UX comments in #27

"I am a bit worried that with "Add block field" we leave out the ability to add "non-block" fields, and that no one knows what a "block" field is. "

Perhaps it should be "Add block" not "Add block field".

Other contrib may also want to add things here, and field group already does. But this is the first time in core so there's no pre-established pattern. Perhaps rather than having a different button for each thing that can be added, the pattern should be a dropbutton here condensing them.

I'm not sure whether this should be done as part of this issue or separate, and if separate whether it should follow after this issue (abstracting out the add functionality) or precede this issue.

Eventually after #1875974: Abstract 'component type' specific code out of EntityDisplay the buttons could be generated dynamically based on component plugin metadata, but the UX pattern can be established independent of this.

@jonathanshaw it could be done as selection of type in modalif there will be more then 10 types, but not clear how this action link with dropdown may look like

Rerolled.

When this patch is used with Layout builder enabled the field blocks are available which leads to weird behaviour and UX.

I tested it on user manage display admin/config/people/accounts/display/default. I did a clean install and then enabled layout builder

1. The content field blocks where showing up for some reason and also duplicated
   
2. The user field blocks show up
   
   but sense all the field blocks show up regardless of whether they view configurable which kind makes that field property useless. Because it doesn't mean what it use to.
3. also if you have placed a field like picture it is kind of weird next to the non-block field
   the label is exactly the same
   
   but then they have pretty much have the same settings just in a different form
   

Should the layout builder itself exclude field blocks from this list?

I'm not even sure we want to do this still. Don't ask me why I bothered to reroll it...

Yeah, I would just close this too :)

Ok closing as outdated because you could now just use Layout Builder to get this functionality and more