Derived from #1183042: Regression: Add WAI-ARIA roles to Core blocks, allow module maintainers to inject attributes and classes into blocks by adding "attributes" to hook_block_view(). system_preprocess_block() is a good example of why this is a good thing as it saves us having to write another preprocess function.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RobLoach’s picture

Right now, if you have a module where you're creating a block where you need a specific block class, you need to use:

mymodule_block_view() {
  $block['subject'] = t('Hi thare!');
  $block['content'] = '<div class="mymodules-specific-class"'>' . $content . '</div>;
  return $block;
}

It makes infinitely more sense to use:

mymodule_block_view() {
  $block['subject'] = t('Hi thare!');
  $block['content'] = $content;
  $block['attributes']['class'][] = 'mymodules-special-class';
  return $block;
}
Jacine’s picture

Thanks Rob!

So, my question is can this be done for nodes too? And anything else?

Jeff Burnz’s picture

Subscribe :)

RobLoach’s picture

I was thinking about this last night as @Jacine does make a good point. The key difference between Blocks and Nodes, however, is that Blocks are not Entities. Blocks are containers for content on your site. They hold content, doesn't matter what it is, they just display it. This means we either:

Add a "attributes" parameter to hook_block_view()
This doesn't really fit in with the rest of the Drupalism we have, which Jacine pointed out.
Turn Blocks into Entities
But Blocks are just containers for other content, so they don't really make sense as entities.
Turn Blocks into Renderable Arrays
And this is the solution I came to. Having Blocks as renderable arrays mean that we can have any kind of content in there, we can stick in any attributes we want, and it fits with the rest of our Drupal ideology.

...... or am I just crazy?

Jacine’s picture

Not crazy at all. I thought blocks were going to turn into entities though? Anyway, blocks should definitely become render arrays. I think the only reason they weren't switched over in D7 was because there wasn't time. It's totally weird that they are not right now.

The main thing here that I am concerned about is that ALL attributes are done the same way for consistency. I still worry about being able to manipulate them fully in preprocess functions. I have run into some funky situations in D7 where pre render functions destroy the theme's ability to make preprocess/preprocess changes. Though, if anyone screws around with attributes in that way, I guess that would be pretty dumb.

Everett Zufelt’s picture

If we made blocks into renderable elements (which i am in support of), we could do:

#type = block
#attributes][class][] = my-block-custom-class
#title = My block title // This is currently 'subject'
#title_display = invisible // If you want to hide the title
... // the rest of the content of the block.

indytechcook’s picture

Cross post with #430886: Make all blocks fieldable entities

Blocks are going toward entities. The block rendering should be a render array. The other issue is now focused on making the custom block entities. If we end up with all blocks as entities then blocks will return render arrays.

@Rob Loach that statement isn't true. $block['content'] expects a render array. see http://api.drupal.org/api/drupal/modules--block--block.module/function/_...

xjm’s picture

Status: Needs review » Needs work
Issue tags: +Novice

Thanks for your work on this patch. Note that the Drupal 8.x patch will need to be rerolled, because the core directory structure for Drupal 8 has now changed. (For more information, see #22336: Move all core Drupal files under a /core folder to improve usability and upgrades). When the patch has been rerolled, please set the issue back to "Needs Review."

Tagging as novice for the task of rerolling the Drupal 8.x patch.

If you need help rerolling this patch, you can come to core office hours or ask in #drupal-gitsupport on IRC.

michaelfavia’s picture

Status: Needs work » Needs review
FileSize
7.24 KB

Rerolled post core move.

JohnAlbin’s picture

I'd like to point out that block contents are already renderable arrays. If you have a module that is producing a block and its contents aren't a render array, that's arguably a bug.

That still doesn't solve the problem of wanting to add attributes to the block.tpl wrapper.

Still, I think converting blocks to entities sounds more interesting. And would likely mean any work here would need to be undone or re-done.

Jacine’s picture

I'd like to point out that block contents are already renderable arrays. If you have a module that is producing a block and its contents aren't a render array, that's arguably a bug.

@JohnAlbin So why aren't we using render() for $content in block.tpl.php? Did this just happen in D8 or is it this way in D7 too?

Should we just postpone this for now?

moshe weitzman’s picture

Status: Needs review » Needs work

It is correct that the preferred return from hook_block_view is a render array in D7. We didn't convert all blocks because it didn't seem that important for the simpler ones, and it takes time to push those patches in.

I think block.tpl.php does not use render() becasause it is a called as a theme_wrapper, not by theme(). So it gets handed already rendered $content and not a render array. All it does is "wrap" that content in the usual block markup.

So this issue seems 'works as designed' or needs to focus more on converting legacy blocks.

catch’s picture

So I haven't tested this - if a block returns a render array, can it add affect attributes in block.tpl.php or not currently?

catch’s picture

Title: Add "attributes" to hook_block_view() » Ensure render arrays properly handle #attributes and add them there instead of preprocess hooks
Priority: Normal » Major
Issue tags: -Novice

I'm going to commit #1183042: Regression: Add WAI-ARIA roles to Core blocks. Using preprocess is not ideal at all, but hook_preprocess_node() shows that's the current standard. If everything works already, then we can use this issue to track converting older code that's relying on preprocess to use it.

Re-titling and bumping to major.

Eric_A’s picture

if a block returns a render array, can it add affect attributes in block.tpl.php or not currently?
Not really.
A quick fix might be to change $build in _block_get_renderable_array() to basically stuff everything except the theme wrapper in a child element, and then have the function provide a build alter to add our #attributes or #attributes_array to the parent. (#attributes would need to be preprocessed.)

Eric_A’s picture

Oops, _block_get_renderable_array() is D7.
In D8 there already is a child element for content and thus a parent element to have its very own attributes. So why not use #theme now instead of #theme_wrappers and convert the block preprocessors?

Currently you would still have to rely on page altering to add attributes to a main block element.

Eric_A’s picture

I guess it's alright to pass #attributes next to #children to a theme wrapper, so no urgent need to switch to #theme. (See template_preprocess_region() for the #children and #region variant.)

So if it were alright to have hook_block_view() return a renderable block with a 'content' child, we could add both "content attributes" and "wrapper attributes" there. Then block_get_renderable_region() would add the final theme wrapper and template_preprocess_block() would populate $attributes_array.

Such a patch would touch every implementation of hook_block_view() and hook_block_view_alter(), but would allow for early initialization of WAI-ARIA role attributes.

David_Rothstein’s picture

I created #1402250: Allow modules to classify blocks when defining them, so WAI-ARIA roles can automatically be added in the theme layer to follow up on the WAI-ARIA roles.

It may or may not wind up relying on this issue (I personally prefer the implementation that doesn't), but either way I think this issue is a good one to solve :) Having to use a preprocess function to add an attribute is definitely annoying.

mgifford’s picture

Status: Needs work » Needs review
Issue tags: -block.tpl.php, -hook_block_view

#9: hook_block_view-attributes.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +block.tpl.php, +hook_block_view

The last submitted patch, hook_block_view-attributes.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Postponed
Issue tags: +Blocks-Layouts

This is almost exclusively about blocks, and #1535868: Convert all blocks into plugins will drastically change all of this, possibly even rendering it obsolete, so postponing.

effulgentsia’s picture

Status: Postponed » Active

Unpostponing. I also re-opened #1183042: Regression: Add WAI-ARIA roles to Core blocks to specifically track the regression of the role attribute, though maybe this issue will fix that.

sun’s picture

tim.plunkett’s picture

Priority: Major » Normal

This should be more than possible now.
BlockPluginInterface::build() (effectively the replacement for hook_block_view) now requires returning a render array.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

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

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

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should 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.

tim.plunkett’s picture

Issue summary: View changes
Issue tags: -Blocks-Layouts

Not actively part of the Blocks-Layouts work.

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

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

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

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

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

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

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

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

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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.8.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. 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.

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

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.