Attributes of a block content are applied to block itself

Created on 10 May 2015, about 10 years ago
Updated 19 May 2025, 15 days ago

If a block returns a renderable array and the array has direct attibutes they will be "stolen" from the original content and applied to the block itself.

For example a if a block returns something like this:

array(
  '#attributes' => array(
    'class' => array(
      'foo-bar'
    ),
    'data-test' => 'This is just a test'
  ),
  '#markup' => 'This is block content'
);

The rendered HTML will be:

<div id="block-foobartest" class="foo-bar" data-test="This is just a test">
  This is block content.
</div>

instead of:

<div id="block-foobartest">
  <div class="content foo-bar" data-test="This is just a test">
    This is block content.
  </div>
</div>

This is especially bad for blocks that represent forms since none of the form attributes is preserved.

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
BlockΒ  β†’

Last updated 3 days ago

Created by

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

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

  • πŸ‡ΊπŸ‡ΈUnited States scottsawyer Atlanta

    I am running into this problem with exposed forms in blocks, but it only surfaced when I updated to D 9.5. I was using views_block_filter_block because my views were block displays and I needed the exposed filters in separate blocks. It seems like the D9 update superseded views_block_filter_block, changing where the attributes were attached.

    I patched with the MR, but it doesn't seem to be working, exposed form class attributes are still being moved to the containing block. If you have a custom block template for blocks containing views exposed forms that don't output all of the attributes, it breaks the ajax as well as the CSS in my case.

    I worked around the issue by refactoring my template structure, I was fortunate to find a relatively simple solution, unfortunate that it cost me half a day to discover the problem and fix it.

  • πŸ‡ΊπŸ‡ΈUnited States dcam

    dcam β†’ changed the visibility of the branch 2486267-attributes-of-a to hidden.

  • πŸ‡ΊπŸ‡ΈUnited States dcam

    dcam β†’ changed the visibility of the branch 11.x to hidden.

  • πŸ‡ΊπŸ‡ΈUnited States dcam

    Based on comment #10 I checked to see if this is still an issue in Drupal 11. It is. The same problem with the Search block form's data-drupal-selector attribute being applied to the block wrapper still exists.

    There was no need to make a new test for this. The test created for the related original issue, #2171269: Handle block rendering's #attributes correctly (fixes in-place editing of custom blocks) β†’ , can be adapted to check the change.

    MR 1402 was broken. I don't know why some of the additional changes in it were made because they aren't well documented. The change from #atrributes to #wrapper_attributes was lost. I think that's the reason for the confusion in the more recent comments. I'm sure that it did stop doing anything to fix the issue. Since it's difficult or impossible to rebase MRs for old Core versions anyway, I hid the branch and created a new one for D11 restarting from the #5 patch. We'll see if this causes other tests to fail.

  • Merge request !12168Updated BlockHtmlTest β†’ (Open) created by dcam
  • Pipeline finished with Failed
    15 days ago
    Total: 554s
    #500581
  • πŸ‡ΊπŸ‡ΈUnited States dcam

    I didn't expect it to pass. I assumed that something else was probably relying on the attributes as they were. Oh well.

    I made a change record: https://www.drupal.org/node/3525287 β†’ .

  • πŸ‡ΊπŸ‡ΈUnited States dcam

    I worked on this issue over the weekend not realizing that I'd experience it first-hand two days later. I've been adding inline styles to the .views-exposed-form class. Then I navigated to a different page where the exposed form is in a separate block. The class was bubbled up to the block wrapper, causing the block heading to be displayed in-line with the form as shown in the image below.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    This seems like it could be an immediate breaking change if I had css written for before.

Production build 0.71.5 2024