Problem/Motivation

Within a templateregion--header.html.twig we render a block "manually" by calling " a custom block via {{ elements.my_project_block_plugin_1 }}. This leads to a fatal error in case the custom block plugin returns an empty markup string

  public function build() {
    // [...]
    return [
      '#markup' => '',
    ];
  }

:

Error: Call to a member function getPlugin() on null in Drupal\block\BlockViewBuilder::preRender() (line 203 of core/modules/block/src/BlockViewBuilder.php).

It appears that some circumstances lead to the block being rendered a second time, although it has been rendered before and has been marked as #printed already:

  1. Region "header" is rendered in page.html.twig as {{ page.header }}.
  2. This leads to all children being render processed and concatenated to #children beforehand.
  3. As the region template itself renders the child directly via {{ elements.my_project_block_plugin_1 }}, the block is passed to \Drupal\Core\Template\TwigExtension::escapeFilter() once again.
  4. There the check on the element being already renders fails, as it also checks on strlen($arg['#markup']) > 0.
  5. This leads to the re-rendering of the block - at least the try of it.

From my perspective this seems like a generic bug, as this may lead to multiple render processing of elements that simply will fall back to an empty string.

Proposed resolution

* Remove the general check on strlen($arg['#markup']) in

// Early return if this element was pre-rendered (no need to re-render).
if (isset($arg['#printed']) && $arg['#printed'] == TRUE && isset($arg['#markup']) && strlen($arg['#markup']) > 0) {
   return $arg['#markup'];
}

appearing in \Drupal\Core\Template\TwigExtension::escapeFilter() and \Drupal\Core\Template\TwigExtension::renderVar()

Remaining tasks

* Write a test.
* Clarify what the intensions were in #2464045: Move twig_render_var/twig_drupal_escape_filter to TwigExtension, inject the renderer in Twig extension and inline render() / show() function instead of calling it of adding strlen($arg['#markup']).
* Fix

User interface changes

-

API changes

-

Data model changes

-

Comments

derhasi created an issue. See original summary.

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

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

acbramley’s picture

Version: 9.5.x-dev » 11.x-dev
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Bug Smash Initiative

Just on 6 years with no futher comments, is this still an issue?

The strlen check still exists in 11.x, and the description in the IS is a bit confusing, specifically:

This leads to the re-rendering of the block - at least the try of it.

But the code comments state the opposite - i.e it's trying to prevent re-rendering.

If the problem still exists, please provide steps to reproduce from a fresh installation of Drupal core.

Thanks!