Render blocks later, so they can be placed individually in a region template

Created on 21 October 2020, over 4 years ago
Updated 23 May 2024, 8 months ago

Problem/Motivation

Every region template (eg. core/modules/system/templates/region.html.twig) uses {{ content }} to render the blocks in that region. But unlike node templates (eg. core/modules/node/templates/node.html.twig), where you can do things like {{ content|without('field_example') }}, the content of a region cannot be manipulated. This is because the content variable of a region is not an array of renderable elements, but just a string of rendered HTML.

Sometimes you want to be able to have access to the separate blocks, for instance to do something like this:

  <div class="grid-container">
    {{ content|without('special-block') }}
  </div>
  {{ content.special-block }}

Proposed resolution

The reason why blocks arrive in the template as an already rendered blob of HTML, can be found in the comments on line 439 and 440 of core/lib/Drupal/Core/Render/Renderer.php:

// If #theme is not implemented or #render_children is set and the element
// has an empty #children attribute, render the children now. [...]

This also points us in the direction of a solution: Build the render array of a region with a #theme property instead of a #theme_wrapper. As far as I can see, this results in the exact same output as the current situation, requiring no changes to twig templates, while adding additional flexibility for those who need it.

Remaining tasks


No reasons have been brought forward.


None, except that a little more function nesting (still well within reasonable limits) might theoretically slow down xDebug.


Manual testing has shown that caching works as expected, also when making use of the new capabilities we are adding. Also, all automated tests pass.


This is not a problem if we target the 10.x-alpha release, see comment #47.

User interface changes

none

API changes

none (see also comment #34)

Data model changes

none

Release notes snippet

Do we need one?

Feature request
Status

Needs work

Version

11.0 🔥

Component
Theme 

Last updated about 20 hours ago

Created by

🇳🇱Netherlands marcvangend Amsterdam

Live updates comments and jobs are added and updated live.
  • Needs frontend framework manager review

    Used to alert the fron-tend framework manager core committer(s) that a front-end focused issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

  • Status changed to Needs review almost 2 years ago
  • 🇳🇱Netherlands idebr

    Reroll for 10.1.x

    #59 still needs to be addressed.

  • Status changed to Needs work almost 2 years ago
  • 🇧🇪Belgium borisson_ Mechelen, 🇧🇪

    Needs work for the nitpick in #59

  • 🇯🇵Japan tyler36 Osaka

    Exactly what I was was looking for!
    Confirmed working on Drupal 10.1.3 on demo site.

    I'm attaching the results of a test output similar in scope to #43.
    The zipfile contains HTML output of pages with Twig and cache debugging on so you can see the template, caching and rendering times.

    ## Test

    1. Installed Drupal 10.1.3 using Umami profile
    2. Cleared cache
    3. Used wget to get static version of site (see UmamiPages.zip|pre-index.html)
    4. Cleared cache
    5. Applied patch #61
    6. Cleared cache
    7. Used wget to get static version of site (see UmamiPages.zip|post-index.html)
    8. Used wget to get static version of site (see UmamiPages.zip|post2-index.html)

    You can see the cache hashes and render time change between 3 and 7.
    Steps 7 & 8 produced identical pages (no cache clear between).

  • Status changed to Needs review about 1 year ago
  • 🇳🇱Netherlands watergate

    Thanks a lot for the patch(es); this functionality was/is missing. I can confirm that everything works perfectly on Drupal 10.1.6.

    I agree with the nitpick in #3178202-59: Render blocks later, so they can be placed individually in a region template and think that @group Render makes the most sense (and is in line with the rest of the test classes in the namespace). I've updated the patch with the small change :)

  • last update about 1 year ago
    30,606 pass
  • Status changed to RTBC about 1 year ago
  • 🇧🇪Belgium mollux

    patch in #65 works as expected, I'm able to prevent certain blocks in a region to be rendered

  • 🇮🇹Italy Giuseppe87

    Does the #65 requires some manual action?

    If I install it, every region.html.twig in the site has the content variable valued as an emtpy string, killing pretty much the render of the site.

  • Status changed to Needs work about 1 year ago
  • 🇳🇱Netherlands watergate

    Does the #65 requires some manual action?

    After applying the patch, everything should work as before. Using {{ content }} should still produce the same output as before. The extra functionality of the patch is that you can output specific blocks like {{ content.page_title }} and {{ content|without('page_title') }}.

    Please let us know if you can reproduce the problem using a clean install.

  • 🇮🇹Italy Giuseppe87

    I've tried with a D10 clean install and the patch doesn't cause the same problem.

    I've identify that the bug I'm facing appears when using the Bootstrap theme .

    Being this a core issue, I guess the theme needs to solve the incompatibility, after this patch is merged.

  • Status changed to RTBC about 1 year ago
  • 🇧🇪Belgium borisson_ Mechelen, 🇧🇪

    I'll set this back to rtbc, after #68/#70 tested manually that with just core, this patches fixes the issue.

  • Status changed to Needs review about 1 year ago
  • 🇬🇧United Kingdom catch

    Changing render arrays in a minor release is OK, but that's quite major breakage of the bootstrap theme - I think we need to figure out why it's not rendering anything after the change, and either look at whether there's a way to keep it working, or open an issue against bootstrap with how it should change (which will need to support versions of core before and after this change).

    Moving back to needs review for that.

  • Status changed to Needs work 8 months ago
  • 🇪🇸Spain luismagr

    Hi all,

    I'm running 10.2.5 and I can confirm it works as expected. I'm building a new theme started with the starterkit and this is working perfectly fine.

    I'm not putting this issue back to 'Reviewed & tested by the community' because I can't confirm if it's working or not in a boostrap theme.

    Thanks all for your work on this issue

Production build 0.71.5 2024