Problem/Motivation

When I display a custom block using the block layout configuration the block prints using the block.html.twig template however if I have a custom block view each row is just the rendered fields, not the whole rendered block.
This causes problems for themers and is inconsistent with similar row formats like "Show: Content" for nodes.

This also means that contextual links don't show for blocks in a view.

Steps to reproduce:

  1. Create a custom block
  2. Create a view showing custom blocks
  3. For the view format select Show = Custom block

Proposed resolution

For this "Show: Content block" row type the row should be the rendered block, not just the fields.
If you want individual fields you would choose "Show: Fields" instead.

Files: 

Comments

rooby created an issue. See original summary.

rooby’s picture

Title: Custom block views don't use block template » Custom block views don't use the block template
rooby’s picture

Issue summary: View changes
rooby’s picture

Version: 8.0.4 » 8.1.1

This is still a problem on 8.1.1

rooby’s picture

Version: 8.1.1 » 8.1.x-dev
agentrickard’s picture

Version: 8.1.x-dev » 8.2.x-dev
Priority: Normal » Major
Issue tags: +DX (Developer Experience), +Twig, +DrupalWTF

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

genzer’s picture

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.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

danbohea’s picture

@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.

agentrickard’s picture

FileSize
845.67 KB
26.63 KB

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

A picture of a themed block output

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

A picture of a themed block output

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.

agentrickard’s picture

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.

agentrickard’s picture

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

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

xjm’s picture

Issue tags: +VDC
osman’s picture

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.

osman’s picture

xjm’s picture

Priority: Major » Normal

@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!

danbohea’s picture

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

Wim Leers’s picture

Component: block_content.module » views.module

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.

Berdir’s picture

Component: views.module » block_content.module

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.

Wim Leers’s picture

Berdir++

danbohea’s picture

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?

Berdir’s picture

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

larowlan’s picture

This is a won't fix for me.

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

rooby’s picture

While I don't really understand the logic in not fixing it I'm happy to accept the decision.

If it doesn't get fixed though can we remove the "Show = Custom block" option for these views, since it doesn't work consistently with similar settings for other entities and it is effectively the same as using "Show: Fields"?

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)

If they were always expected to be rendered as a block, why can't views render it as a block?
If I put on my site builder or themer hat, that is what I would expect to happen.

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

To a lot of end users it is, and there is no non-content block view available.

lpeabody’s picture

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.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Wim Leers’s picture

Title: Custom block views don't use the block template » Custom block views don't use the block template: ability to display block_content entities independently, also outside of Blocks
Category: Bug report » Feature request

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

Indeed. Which makes this a feature request.

Wim Leers’s picture

Status: Active » Closed (works as designed)
Issue tags: +BC break

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.

Wim Leers’s picture

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.

rooby’s picture

@Wim Leers
Is it out of the question technically that views can't display a content_block entity as a block (I haven't actually looked into it)?
It seems that what views currently does goes against the title of the issue you just created.

DamienMcKenna’s picture

Title: Custom block views don't use the block template: ability to display block_content entities independently, also outside of Blocks » Ability to display block_content entities independently, also outside of Blocks
Version: 8.4.x-dev » 9.x-dev
Status: Closed (works as designed) » Active

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.

DamienMcKenna’s picture

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