Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
In order to contain logic across all block types, BlockBase implements the public methods and then delegates to a protected method.
This prevents nasty chains of parent:: calls.
#2278541: Refactor block visibility to use condition plugins moves visibility logic from the block entity down to the block plugin, and makes this even more necessary.
Proposed resolution
Add a blockAccess() method.
Remaining tasks
N/A
User interface changes
N/A
API changes
All blocks currently implementing access() should implement blockAccess() instead
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | block-2283969-1.patch | 7.78 KB | tim.plunkett |
Comments
Comment #1
tim.plunkettComment #2
tim.plunkettComment #3
blueminds commentedLooks good.
Comment #4
berdirDoes this need a change record (update), I guess the current access would still work but will break eventually when access() does more?
Comment #5
chx commentedI do not see how this could introduce another sechole so good to go.
Comment #6
webchickOk, had few moments where I was concerned about one-offing Block's access stuff here, but was pointed to https://api.drupal.org/api/drupal/core%21modules%21block%21src%21BlockPl... which shows we are already doing that for e.g. blockForm, blockValidate, etc. so this just brings that code inline.
Talked to Tim about the change notice, he's going to go through and update all of them, under penalty of a picture of a sad pit bull. ;)
Therefore, committed and pushed to 8.x. Thanks!
Comment #8
tim.plunkettUpdated https://drupal.org/node/1880620, thanks!
Comment #9
tim.plunkettComment #11
dawehnerNote: If we do move block visibility into the base class you can basically never just implement the interface. Block visibility is kind of orthogonal to pure access and could be implemented somehow outside.