Ability to display block_content entities independently, also outside of Blocks

Still an issue, and particularly troubling as it breaks expected behavior.

So, I tried to reproduce the problem through block.twig.html pattern - block displayed completely, also all available fields (title and body), where the title displayed depending on the configuration of the block. Throught the views view showing custom blocks format select Show: "Custom block" , only body field displayed. That's what I thought you meant. If i am not right, could you please be more specific in your request and provide me with the detailed information regarding your issue? Isolate the conditions under which the problem appears as narrow as you can it helps to find its cause faster.

@genzer The problem is that a block's template is not used when a block is rendered within a view. The giveaway for me was enabling theme debugging and inspecting the markup of a view of custom blocks - I'd expect to see block.html.twig suggested as a possible template within each views row but it's not.

Here's a concrete example for people new to the issue.

This is a block, output via the block system, themed with block--themename-blockid.html.twig

This is the same block, output using a View that displays block entities, displayed in the same theme.

Using Twig debugging, no block template suggestions are made.

In other cases, I had to not use the entity display view settings, and output and theme views fields.

In the case of Nodes, I believe that template files are applied. But for custom blocks, they are not.

And here's what Twig is suggesting as template options.

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_unformatted' -->
<!-- BEGIN OUTPUT from 'themes/custom/pnet/templates/views/views-view-unformatted.html.twig' -->
  

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'field' -->
<!-- FILE NAME SUGGESTIONS:
   * field--block-content--field-background-image--hero.html.twig
   * field--block-content--field-background-image.html.twig
   * field--block-content--hero.html.twig
   * field--field-background-image.html.twig
   * field--image.html.twig
   x field.html.twig
-->

Note that it never even thinks about loading a block template.

I ended up having to duplicate the block template logic inside a Views-discoverable template.

views-view-unformatted--homepage-hero.html.twig

I also confirm the bug.

Regardless of which style format is selected (Grid, HTML List or Unformatted list *), Custom block row plugin always uses the fields handler.

I tried it with with both Default or Full view modes, but no use.

* The other available plugin Table doesn't offer any row style.

@lauriii, @Cottser, @joelpittet, @alexpott, and I discussed this issue awhile back. It's clear that this is a bug, but it does have a workaround and can be handled as normal prioirty. (See https://www.drupal.org/core/issue-priority#major-bug for the criteria for major bugs.)

Thanks everyone!

@xjm What's the workaround? Please don't say #12.

The problem is that a block's template is not used when a block is rendered within a view. The giveaway for me was enabling theme debugging and inspecting the markup of a view of custom blocks - I'd expect to see block.html.twig suggested as a possible template within each views row but it's not.

This really seems like a Views bug per that description in #9.

That has absolutely nothing to do with views.

The problem simply is that block_content entities explicitly have no defined #theme/template because they were expected to always be rendered as a block (core, page_manager, .. doesn't matter, but it has to be a block)

BlockContentViewBuilder:

  /**
   * {@inheritdoc}
   */
  protected function getBuildDefaults(EntityInterface $entity, $view_mode) {
    $build = parent::getBuildDefaults($entity, $view_mode);
    // The custom block will be rendered in the wrapped block template already
    // and thus has no entity template itself.
    unset($build['#theme']);
    return $build;
  }

this isn't views specific, it also affects entity references for example in exactly the same way.

block_content entities simply aren't designed to be displayed in another way, if you check the view builder you can also see that it explicitly works around render caching and has that disabled.

So the answer to this might simply be that this is on purpose, if you want to display something with views or references or ..., then don't use block_content but either a node type or custom entity type. I understand that not everybody will like that but I'm not sure I see an alternative for keeping it working correctly and efficiently (=no double-render caching of the same content, for example) also within a block.

Berdir++

Given the conclusion in #19 and what people's expectations are (resulting in this issue), would it therefore make sense to prevent users from creating views of blocks?

That's not really possible, because creating views of blocks to show them in a table is perfectly valid.

This is a won't fix for me.

A block isn't the same as a block content entity.

I think there are plenty of instances where site builders will jump at the opportunity to reference blocks through other entity reference fields, for whatever reasons, and be shocked/dismayed that they can't theme them the way they're able to theme other entity types. It should be supported in some fashion.

block_content entities simply aren't designed to be displayed in another way

Indeed. Which makes this a feature request.

With a grand total of 15 people following this issue over the course of almost a year, and given the very complete explanation by @Berdir in #19, I think it's clear that this is working as designed.

If people strongly disagree, then this will have to be a Drupal 9 feature request, I'm afraid, because this would cause a big BC break.

I think the best we can do, is document this, so that people in the future won't have to open more issues like this one. Created #2859197: Document that block_content entities are not designed to be displayed outside of blocks for that.

Reopening this as a feature request for D9, because it's a major DrupalWTF moment when you realize this. It's also almost 18 months since D8 was released, there's no documentation about this and there's functionality available in core to trigger this bug.

For D9 should we separate the custom entities from the "pieces of data or functionality that may be positioned on a page" system?

I would propose a new approach for D9.

Separate content data from configuration in the block system.
block_content should be an entity with the same capabilities as other entities including a dedicated template and not rely upon block configuration.

I would also like to see the ability to assign any entity to the block configuration and not isolate it to block_content.
For example, if I wanted to create a block with a node teaser in it.

I just ran into this issue, myself. I had assumed that blocks would be template-able even if embedded via paragraphs entity reference field, and was disappointed to find that they are not. As a workaround I'll convert all my custom blocks to content types, so that ultimately a content manager can manage page content in a stacked/sectioned content sort of way (akin to Wordpress ACF Flexible Layout).

Chiming in not to harass, but to add weight to this feature request. Wim mentioned there were only 15 people following this issue so therefore this is working at intended...make that 16, now. I also believe that anyone attempting to use blocks via an entity reference field would assume that those blocks would be template-able, with quick-edit links present.

Hi all, this is not a fix, but a work around for custom block types that I am using. I'm basically looking for the #bundle within the $variables in hook_theme_suggestions_HOOK_alter(). It will exist within the array items that represent the fields: $variables['elements']['content']['field_name']['#bundle']. If it exists you can create your own theme suggestion. It's sort of a lame way to deal with this but I can't find another way. I hope this helps!

/**
 * Implements hook_theme_suggestions_HOOK_alter().
 */
function YOURTHEME_suggestions_block_alter(array &$suggestions, array $variables) {
  if(isset($variables['elements']['content']['body'])) {
    if($variables['elements']['content']['body']['#bundle'] == 'pre_footer_contact_block') {
      $suggestions[] = 'block__pre_footer_contact_block';
    }
    if($variables['elements']['content']['body']['#bundle'] == 'microsite_footer') {
      $suggestions[] = 'block__microsite_footer';
    }
  }
}

fwiw - https://github.com/swentel/block_content_template aims to resolve the template/contextual links problem
will sync back to d.o if more people are interested

@Swentel, does this also fix the issue that block that are rendered through views don't use a block template? If that it is the case, then I would really appreciate seeing it on d.o.

@K3vin_nl It doesn't use the block template, but is using a template that the module defines: block-content-template - with suggestions too. Makes it easier to target (that's at least what my themers told me :)

Do they say why it is easier to override your new template instead of an equivalent block template?

The suggestions in the block module do not add a suggestion for the block type. Granted, it's probably doable by implementing a preprocess function. We're evaluating the module right now and works fine for our purpose (especially having the contextual links). Another reason that I didn't use the #block theme function is that it triggered tons of notices because it's expecting a lot of properties which neither layout builder or views add, so I would have had to implement another preprocess function to provide fake properties which don't really matter.

However, fair point though, so I will see if I can iterate on it.

@Swentel Your module sounds very interesting. +1 for getting this on d.o.

I believe that a related issue is if you theme a block that is referenced with entity_reference_revisions (eg. as a paragraph field) you will not able to theme the block (ie it is block_content). Partly I'm just commenting to fill the void of online wisdom there seems to be around this space.

In response to #28, Drupal 8 has been out for a while now and a lot more sites have been built with it. There are now more followers of this issue.

I'd like to see "render as a block" as option at least in Drupal 8 so entity reference fields behave the same way for blocks as for every other entity. Whatever the original intent of blocks, they seem to be fully fledged entities now. Even Layout Builder allows placing blocks as content directly on a page.

Perhaps this could be tested in contrib, taking #39 into account.

Just adding that just because I wasn't following this issue didn't mean I wasn't banging my head over this several times in projects. Now following

I faced with a similar issue when was outputting custom blocks programmatically. Contextual links weren't shown on page. Here's a solution that helped me https://github.com/ygstand/block_content_contextual_links

I'd really like to see a solution for this. It doesn't make any sense to anyone who wasn't deeply involved in the original architecture of blocks. The rest of us see something that appears be be broken. In my situation, I'd like to reuse block types that were originally created to be used within Layout Builder within an entity reference field on a content type where Layout Builder is not enabled. A hero block type for example. It makes no sense to recreate the functionality that the block type already provides when I am just one simple template away from being able to just reuse it. Following.

I want to add that Drupal 8 has brought us so much ability to build out reusable components with block types and Layout Builder. It's really amazing... But then you run into things like this that are so frustrating and force you to rebuild the component you already built. We're so close but so far.

I realized I actually have come across this problem before:

https://drupal.stackexchange.com/questions/267150/render-custom-block-us...

The work around I found then was to use Twig Tweak. I tried very hard to find a solution that doesn't involve another module at the time and failed. I've spent a few hours this time trying to do the same and failed again. So Twig Tweak it is I guess. Since I'm certain I will end up Googling this problem again and will find this thread, I'm posting this here for my future self and anyone else:

Tweak Tweak work around

First a couple facts:

• I have an entity reference field with machine name field_hero_block_ref.
• It references a block type with machine name of hero.

In theme .theme or custom module .module file (this is in my custom module oh_block_types.module):

/**
 * Implements hook_preprocess_TEMPLATE().
 *
 * Preprocess field--field-hero-block-ref.html.twig.
 */
function oh_block_types_preprocess_field__field_hero_block_ref(&$vars) {
  // Get block uuid and pass to template. We need BlockContent entity to
  // render with block.html.twig template/preprocess hook which it doesn't
  // in order for Hero block type to render with proper styling and markup.
  // See: https://www.drupal.org/project/drupal/issues/2704331#comment-13389866
  if (isset($vars['items'][0]['content']['#block_content'])) {
    $block_id = $vars['items'][0]['content']['#block_content']->id();
    $block_entity = BlockContent::load($block_id);
    if ($block_entity) {
      $vars['block_uuid'] = 'block_content:' . $block_entity->uuid();
      $vars['block_title'] = $block_entity->label();
    }
  }
}

Create a template for the entity reference field (based on field.html.twig). In your template:

{#
/**
 * @file
 * For Entity reference field which renders Hero block type (used on Basic Page content type),
 * we need to render the block using Twig Tweak. This is because by default a block rendered
 * via an Entity reference field does not use the block.html.twig template/preprocess hook.
 * It's very very stupid.
 * See: https://www.drupal.org/project/drupal/issues/2704331#comment-13389866
 *
 * Available variables:
 * - attributes: HTML attributes for the containing element.
 * - label_hidden: Whether to show the field label or not.
 * - title_attributes: HTML attributes for the title.
 * - label: The label for the field.
 * - multiple: TRUE if a field can contain multiple items.
 * - items: List of all the field items. Each item contains:
 *   - attributes: List of HTML attributes for each item.
 *   - content: The field item's content.
 * - entity_type: The entity type to which the field belongs.
 * - field_name: The name of the field.
 * - field_type: The type of the field.
 * - label_display: The display settings for the label.
 *
 *
 * @see template_preprocess_field()
 */
#}

{{ drupal_block(block_uuid, {label: block_title}) }}

Your block (or blocks) will now render correctly with the proper block.html.twig template and pass through the corresponding preprocess hook.

This example is to render a single block. If you need to render multiple blocks instead of a single one, then do not delete the default field.html.twig markup like I have here. Instead, replace the rendering of individual items with the Twig Tweak function call. You would also need to modify the preprocess function to use a foreach loop over $vars['items'], and then I think attach the block uuid and title vars to each item.

This is not a great solution. It does work, but you will have to write this code and template for every entity reference field that references a block. If anyone is able to deconstruct the Twig Tweak function to reveal what code it's using, we could potentially do this without Twig Tweak. If we could do this without Twig Tweak, we might be able to do it without creating a template.

I'm not sure I see an alternative for keeping it working correctly and efficiently (=no double-render caching of the same content, for example) also within a block.

Just checking my understanding here... in the normal case of placing a block content entity with the block module, we're trying to avoid having the block content markup render cached for an entity view of block_content and then practically the same markup cached for an entity view of block? Or in other words it's the responsibility of the consumer of the block plugin's render array to ensure it's render cached if appropriate. Is this the only issue with having a template for blocks? (Not downplaying it, just confirming!) I wonder if it would be possible to remove the cache keys from the block content's render array in \Drupal\block_content\Plugin\Block\BlockContentBlock::build() to get caching when viewed as a rendered entity and avoid it when viewed as a block? (Edit: just to clarify, this obviously means we can have double render caching, but it wouldn't automatically double render cache every block content entity placed with the block module.)

So the answer to this might simply be that this is on purpose, if you want to display something with views or references or ..., then don't use block_content but either a node type or custom entity type.

Just following that line of thought, if I build a custom entity type that's similar to block content entities and is for embedded content... I can see at some point being asked to write a plugin to make it accessible to the block system so that we can place these embeddable entities that way too. And then aren't we back in the same situation?

I ran into this as well and modified the snippet in #49 to work for all entity reference fields that reference Content Blocks:

/**
 * Implements hook_preprocess_field().
 */
function mytheme_preprocess_field__entity_reference(&$variables) {
  /** @var \Drupal\Core\Entity\ContentEntityInterface $entity */
  $entity = $variables['element']['#object'];
  $target_entity = $entity
    ->getFieldDefinition($variables['field_name'])
    ->getSetting('target_type');

  if ($target_entity == 'block_content') {
    // Loop over our blocks and pass UUIDs into templates to be used by Twig Tweak.
    foreach ($variables['items'] as &$item) {
      $item['block_uuid'] = $item['content']['#block_content']->uuid();
    }
  }
}

Then in the Twig template you can conditionally load the content like:

{% for item in items %}
  {% if item.block_uuid %}
    <div {{ item.attributes.addClass('field__item') }}>
      {{ drupal_block('block_content:' ~ item.block_uuid) }}
    </div>
  {% else %}
    <div {{ item.attributes.addClass('field__item') }}>{{ item.content }}</div>
  {% endif %}
{% endfor %}

Have you tried this module?
https://www.drupal.org/project/block_content_template

@vector_ray, looks like you moved Swentel's code ( https://github.com/swentel/block_content_template ) to a drupal.org module?
Are there any significant changes to the original module? Does it still use it's own template suggestions?

Really good thinking in #52! Makes the work around for using blocks with entity reference fields a lot more maintainable.

Sorry I haven't had a chance to try the module yet.

@K3vin_nl I did not create the module. I discovered it as well and asked to be a co-maintainer after identifying that it needed some improvements that would help with theming. From the looks of the code it may have originally been a copy of what Swentel had created.

re #54: doesn't such an approach exist outside of B/C guarantees? If the core adds a template proper of its own, isn't there a greater risk to end users getting their markup tweaked on a minor core release?

Really, I'm trying to wrap my head around the whole issue and find the best path forward.

Thinking about this again and discussing it in our team, we're 101% sure that the block_content concept / restrictions should be rethought!

With Drupal moving forward and introducing important innovative functionality like

• Paragraphs
• Layout Builder

you often wish to have an entity type which can be used to put reusable "building blocks" into a central place. Block content is perfect for that!
(But needs some changes into this direction, which are described in this issue).

Even in Drupal 7 you could use Blocks in Panels already, which was really helpful, but there was no block_content library like in D8+. Now as we have it, blocks should be extended to not only live in regions!

Why should we add another entity type while blocks are just perfect for that and the block concept still perfectly fits these needs. So +1 to be able to use block content outside of theme regions and not being forced to place them into a region to use them!
That would also allow to mark certain blocks as "Library Blocks" like for example with https://www.drupal.org/project/block_library

I'd be happy about feedback on this.

> Block content is perfect for that!

They are not really though. block_content entities are exposed as block plugins and saving reusable blocks triggers a block plugin discovery. The more of them you have the more expensive that becomes.

Layout Builder places block_content entities as blocks and paragraphs can do that do through block_field.

Thanks for the technical insight and super fast reply @Berdir :)

Block content is perfect for that!

Indeed, that was meant from the site builder perspective, without the technical view on it! Sorry.

Another issue is that when creating a new block_content, you're taken to the block (placement) creation page afterwards, which is bad for using block_content for such a "reusable building blocks" functionality. But on the other side, I'm struggling hard with adding ANOTHER entity type like blocks for such a central thing... and with Layout Builder in Core I think this isn't clearly a contrib topic.

For me, from the site builder perspective, it still feels like the block(_content) concept could use a next step here, do you think there's room for discussing that? What's your personal opinion?

Thanks a lot in advance and if you think the discussion doesn't fit into this issue, please tell me. I hope it does.

They are not really though. block_content entities are exposed as block plugins and saving reusable blocks triggers a block plugin discovery. The more of them you have the more expensive that becomes.

Can we quantify this expense somehow? Is the cost a linear function, exponential, something else? Would it manifest as a problem when blocks number in the thousands, millions, something else?

Perhaps we should tag this as needing a performance evaluation?

Given that sites have already been using blocks in this way for half a decade because core didn't take steps to prevent it, it's a very real problem, even if core doesn't want to make it more feature complete.

Essentially this is what the Fragments module is trying to do: create reusable pieces of content that don't have all the bells and whistles of a node. The problem with Fragments is that they can't be directly placed in Layout Builder, so if you want to use them as your reusable pieces, you have to create a block type to reference them, which creates some funky UX experiences.

We have a feature request for our platform to create reusable statistic blocks, which would be used to highlight a certain metric that a site owner is proud of. The same statistic might get highlighted in different places. Our potential use cases for reusable stat blocks includes being able to directly place them via Layout Builder in page layouts or potentially adding them via reference field to a more structured content type. Right now, our best idea for how to do this is to use Fragments and to create a Stat fragment type. Then we would need to also have a Stat block type, with a reference field to choose/add a stat Fragment. In the context of Layout Builder, this just makes it a lot more confusing for the user.

We've taken a similar approach to what's described in #66. The block_content layer between Layout Builder and our reusable entities is a very convenient place to expose design system features to content folks.

Quote Block
  --> entity reference field: Select a quote entity
  --> boolean: display quote in overlay container
  --> string list: background color (light, dark, etc.)
  --> boolean: show profile image if available
  --> etc...

This has let the same reusable entity have combinatorial complexity in its display options -- something we've really struggled with using view modes.

I guess in a way we've taken awkward editorial UX lemons and tried to make lemonade with it.

Wow! Another Drupal WTF that got me for hours and hours :) :)

If we are going to push layout builder forward, the separation of building blocks (components) and pages (nodes) makes the most sense to me. The cake layer page-building experience is what Webflow, Wix and other competitors are doing. The ability to reuse existing block components while building pages seems extremely powerful to me and to maintain the theming experience for all entities is also a good idea.

On another note, could we look at how the Block Field module works?

With the field block module, I get a field block plugin option where I am able to choose blocks and then the templates are working.

Wonder if anyone can confirm if #3342998: Add view tab + standard template for block content solves the problem?

Thanks @smustgrave, it'd be great to move this forwards! However there were (at least) a couple of reservations raised with the general idea IIUC:

block_content entities simply aren't designed to be displayed in another way, if you check the view builder you can also see that it explicitly works around render caching and has that disabled.

So the answer to this might simply be that this is on purpose, if you want to display something with views or references or ..., then don't use block_content but either a node type or custom entity type. I understand that not everybody will like that but I'm not sure I see an alternative for keeping it working correctly and efficiently (=no double-render caching of the same content, for example) also within a block.

https://www.drupal.org/project/drupal/issues/2704331#comment-11863202

block_content entities are exposed as block plugins and saving reusable blocks triggers a block plugin discovery. The more of them you have the more expensive that becomes.

https://www.drupal.org/project/drupal/issues/2704331#comment-14604615

I don't really grok the double render-caching issue and it's not clear to me why using a custom entity type might be better

If I build a custom entity type that's similar to block content entities and is for embedded content... I can see at some point being asked to write a plugin to make it accessible to the block system so that we can place these embeddable entities that way too. And then aren't we back in the same situation?

https://www.drupal.org/project/drupal/issues/2704331#comment-13474270