Currently, if you render a Block Content entity outside of a related Block Entity/Plugin, no Contextual links are rendered.
You can see this in core by creating a View of Custom Blocks (rendered as "Default"), which should have contextual links but do not.
If you have Quickedit enabled as well as Contextual you'll also see an error in the console, as "data-quickedit-field-id" attributes are rendered but there is no matching data-quickedit-entity-id.
This all seems related to two quirks in the BlockViewBuilder and the BlockContentViewBuilder:
In \Drupal\block\BlockViewBuilder::preRender(), this block of code bubbles attributes and contextual links up from the Block Plugin's content into the main render array:
...
foreach (array('#attributes', '#contextual_links') as $property) {
if (isset($content[$property])) {
$build[$property] += $content[$property];
unset($content[$property]);
}
}
$build['content'] = $content;
...
You can already see related ramifications of this in issues like #2658270: BlockViewBuilder::preRender() must not mess with block render arrays.
In \Drupal\block_content\BlockContentViewBuilder::viewMultiple(), there is also a bit of code that assumes one rendering context:
// Apply the buildMultiple() #pre_render callback immediately, to make
// bubbling of attributes and contextual links to the actual block work.
// @see \Drupal\block\BlockViewBuilder::buildBlock()
unset($build_list['#pre_render'][0]);
return $this->buildMultiple($build_list);
So to summarize - Block Content entities should support rendering anywhere, with or without the normal Block layout context.
1. Install the latest Drupal 9.x using the standard profile.
2. Clone following repository into modules/custom directory of your project: https://github.com/drupalranger/block_content_contextual
3. Install this module using drush or UI
4. Navigate to /admin/structure/block/block-content and add some custom blocks
5. Navigate to /examples/block_content_contextual and check the output, the page will show 2 lists of custom blocks
5.1 First section will demonstrate default core behavior - no contextual links available
5.2 Second section will demonstrate a fixed state
Example screenshot is attached
| Comment | File | Size | Author |
|---|---|---|---|
| #28 | Screenshot from 2022-11-02 20-59-03.png | 19.08 KB | sandboxpl |
Comments
Comment #2
dsnopekAttempted to make the title so I could understand it better. Feel free to revert if it's wrong!
Comment #3
dsnopekRemoved use of 'context' in the title.
Comment #6
samuel.mortensonI've created a Github repository with a module you can enable to see a clear example of the attributes-side of this problem.
Enable the module from https://github.com/mortenson/block_content_render and visit /block/N/render to see how top-level attributes in a block_content render array are never used. On that page, the given Block Content entity is rendered in two ways - the first uses a View Builder, and the second uses the derived Block plugin to render it instead. You should see that only the second render has the top-level attribute (class) applied.
Contextual links have the same problem, but this was an easier way to replicate the issue.
Comment #8
wim leersLet's first see whether they're actually quirks :)
See #2658270-5: BlockViewBuilder::preRender() must not mess with block render arrays. That code was added intentionally. What's needed there is an explanation + failing test to show what's wrong.
(emphasis mine)
No, they shouldn't. Block Content entities were never designed to be rendered outside of blocks. See #2704331-19: Ability to display block_content entities independently, also outside of Blocks. And yes, this means Panels must do extra work. We had a Panels maintainer sign off on this change in the Block module, see @EclipseGc's comment at #2171269-24: Handle block rendering's #attributes correctly (fixes in-place editing of custom blocks) and -25:
Comment #9
samuel.mortensonAgreed, and Panels does work around this right now by never rendering Block Content entities directly (we always use #theme => block).
In terms of validating if this is quirk - are there any other Content Entity types that have similar problems?
Using Drupal core you can create Views of Block Content entities. Should we explicitly disable that functionality, knowing that they're never supposed to be used outside of a Block config entity?
I think it's safe to say that block_content is unique in core, and that as a module developer it's confusing that I can't render all core Entity Types using their View Builders and have standard components like contextual links work.
Comment #10
wim leersNo. Block Content entities are the only entities whose sole purpose is to be rendered by Blocks, and i.e. whose whole architecture is intertwined with and dependent on Blocks.
This was also asked at #2704331-21: Ability to display block_content entities independently, also outside of Blocks, and answered at #2704331-22: Ability to display block_content entities independently, also outside of Blocks.
Indeed.
Comment #13
ifrikRendered block entities can also used in Views, for example to place them in the header of footer section. That's core functionality.
However, then they don't display a contextual link to allow users to edit them.
One of the use cases is to allow site administrators to edit text in the header region of a view (for example some kind of introduction text) without giving them access to the Views UI. This is a better UX then letting them find the right block in the Custom block library, and it keeps the site safer then giving them access to all Views configuration (which they might break accidentally).
Comment #14
swentel commentedfwiw - 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
Comment #15
sandboxplI tried similar aproach as in #14 , so customizing hook_theme and twig template:
https://github.com/drupalranger/block_content_contextual
Comment #16
ifrikWim,
is this enough info to turn this issue back to active again or is anything else needed?
Comment #18
gnugetThis happening as well with the new Layout Builder.
Not sure if this should be fixed there or in the layout builder.
:-)
Comment #19
sacarney commentedI might have a similar issue.
I have a custom block type, and use a theme template to render it field by field. {{ title_prefix}} is in place. The contextual links don't show up unless I put {{ content }} into the template.
Comment #25
quietone commentedThis issue has had the status Postponed (maintainer needs more info) for 5 years. There have been a few comments since them, the last three years ago. But all the comments were made with a version of Drupal 8, which is now EOL.
Is this issue still a problem?
If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").
Since we need more information to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #26
smustgrave commentedFollowing up on #25
There was no follow up after 3 months so closing out.
If still an issue please reopen and provide the info requested in #25
Thanks!
Comment #27
sandboxplI have just tested this issue against drupal core 9.4.x and it is still a case,
contextual links are not showing up when block content entities are rendered f.e. via custom code,
for easy testing I've just refreshed my custom mini module which quickly demonstrates the issue:
https://github.com/drupalranger/block_content_contextual
Comment #28
sandboxplI've updated the issue summary with possible steps to reproduce the problem
Comment #31
acbramley commentedGiven the lack of activity on this issue and all the reasons described previously by @wim leers around block_content being tied to block config I think this is a won't fix.
I think it would be quite hard to achieve something that wouldn't cause issues for existing sites, and as demonstrated in the demo module it's quite easy to set up your own template to render this out if needed.
Comment #32
dpiI don't think a dependency on Block Config is currently true, and may not ever have been.
Yes, Block Content are expected to be rendered inside the block theme hook/template. But not block config. For example Layout Builder renders reusable Block Content with contextual links on the view entity route just fine.
Perhaps #2704331: Ability to display block_content entities independently, also outside of Blocks will help with putting all Block Content within a block theme hook/template universally, without needing manual wrappers as the #theme=block in
\Drupal\layout_builder\EventSubscriber\BlockComponentRenderArray::onBuildRender.Comment #33
acbramley commentedLayout builder does this via a block plugin, no?
Comment #34
dpiBlock plugins, along with manager, annotation, attribute, etc, are provided by core.