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.Currently, in the function multiblock_call_block(), calls are made to other modules' hook_block_save(), hook_block_configure(), hook_block_view() functions, but the $edit parameter, which contains important information about which instance of a block we're dealing with, only applies to calls to hook_module_save().
This makes it impossible to know which instance we're dealing with when in a module's configure or view hook.
#1672498: Invoke 'block_view_alter' hooks for complete construction of a block has been suggested to get around this, but a better solution, in my view, would be to pass an extra $edit paramter to all block-related hooks when a module declares multiblock-enabled blocks.
This extra parameter allows all block-related hooks to know if they are dealing with the original block, or an instance thereof.
Furthermore, sending an $edit parameter when one is not in the function signature does not seem to cause any ill effects, even with E_STRICT error reporting.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 2112485-1-multiblock-7.x-edit-paramter-to-block-hooks.patch | 2.54 KB | alberto56 |
Comments
Comment #1
alberto56 CreditAttribution: alberto56 commentedHere is a patch
Comment #2
cbeier CreditAttribution: cbeier commentedThe patch looks good to me.
Comment #3
emilymoi CreditAttribution: emilymoi commentedThe patch works but I think it's odd that we're passing 'edit' into view and configure hooks.
Is there a reason we're passing the $edit['multiblock_delta'] as a render array style value in the first place? This seems overly confusing to me. Why not just append the delta to the module invoke call as another parameter? Then we can use the same pattern for view and configure.
Comment #5
intrafusionThis patch has been applied and a new release has been rolled