Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Follow up for #1535868: Convert all blocks into plugins, hook_block_access got added but not documented
Comment | File | Size | Author |
---|---|---|---|
#10 | 1892472_document_hook_block_access-10.patch | 1.15 KB | pcambra |
#5 | 1892472_document_hook_block_access-5.patch | 1.13 KB | pcambra |
#1 | 1892472_document_hook_block_access.patch | 749 bytes | pcambra |
Comments
Comment #1
pcambraComment #2
Dave ReidIt might be good to have a little better example here. Something like if the block is the user login block and the current user is not anonymous, disable access (silly condition since it already does this, but it would at least give something more tangible).
Comment #4
jhodgdonPlease also take a look at the guidelines for documenting hooks:
http://drupal.org/node/1354#hooks
In particular, probably the first line should say "Define access for a block", and the second paragraph should say "This hook is invoked ..." rather than "It is called". It also needs an @return describing what to return and under what conditions.
Also... I definitely agree with #2 - the example should use the global $user I would think, and do something plausible rather than just returning FALSE.
Finally, there should only be one space between the @see and what follows it... and the second @see seems to point to a method that does not exist?
Comment #5
pcambraThanks for the heads up :)
Here's a better patch fixing comments in #4 and with an use example, though I was assuming that examples module would do this kind of stuff.
Hope wording is correct, not native here :)
Comment #6
pcambraComment #7
jhodgdonThe Examples project is for giving examples of how to develop modules using various hooks. It is not a substitute for having good hook documentation, including a reasonably realistic example function body.
Anyway, this patch looks much better to me! At least, I thought it was understandable and follows our documentation guidelines. Thanks!
We need to get someone else who is familiar with the new block/plugin system to review the documentation for accuracy and function body to make sure it would do what it says it is doing. I have no idea.
Comment #8
tim.plunkettThis should be \Drupal\block\Plugin\Core\Entity\Block $block, which we've done elsewhere. Ideally it'd be \Drupal\Core\Entity\EntityInterface, but we're not doing that anywhere else.
@return bool
Powered by Drupal, capital D
This is a fine example, except we use
!=
, not<>
Comment #9
jhodgdonComment #10
pcambraFixed, however the other docs in the block.api.php are referencing BlockInterface... shall we fix those in this same patch?
There are quite a few "@return boolean" here and there in core, is there a task for fixing those already?
Here's a new patch with comments in #8 fixed.
Comment #11
tim.plunkettBoth of those things must have been docs we missed in the conversion, but this one is good.
Comment #12
jhodgdonThanks for the new patch and the review! I'll get it committed shortly.
Please file separate issues for a) the other BlockInterface docs and b) @param boolean / @return boolean [I'm not sure if there are @param boolean instances in core but I imagine there are if there are @return boolean], if you haven't already.
Comment #13
pcambraAbout fixing the comments in block.api.php, I think the right issue for this is #1874576: Improve the documentation and naming of hook_block_view_alter() hooks
I've created one for the @param boolean/@return boolean as I didn't find an existing one. #1897058: Replace "boolean" with "bool" when used as param/return/var type
Comment #14
webchickCommitted and pushed to 8.x. Thanks!
Comment #15
jhodgdon