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.
Problem/Motivation
Block content is not displayed in the panel editor at admin/structure/mini-panels/list/[panel-name]/edit/content. Instead it displays a title of "No info" and content of "No info available."
Proposed resolution
The code in ctools_block_content_type_admin_info() uses the Drupal 6 style of hook_block($op) instead of the Drupal 7 format of hook_block_view().
$block = (object) module_invoke($module, 'block', 'view', $delta);
From a grep of the project source, this appears to be the only such hook remaining to be updated.
Also, as Drupal 7 returns render arrays, it seems the block content needs to be rendered here (unless another place is preferred).
Remaining tasks
Review, write test (?)
User interface changes
None.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#8 | ctools-sanitize-strings-only-1587788-8.patch | 597 bytes | kaidjohnson |
#4 | 1587788-update-hook-block-view.patch | 1.42 KB | solotandem |
#2 | 1587788-update-hook-block-view.patch | 1.23 KB | solotandem |
#1 | 1587788-update-hook-block-view.patch | 1.23 KB | solotandem |
Comments
Comment #1
solotandem CreditAttribution: solotandem commentedAttached patch restores block content display as indicated in issue summary.
Comment #2
solotandem CreditAttribution: solotandem commentedUpon further testing, hit some more use cases:
- block content should be returned as render array from ctools_block_content_type_admin_info() as rendering and sanitization will occur downstream
- block should be returned even if the subject is blank
- block title should be set here (even if subject is blank) as rendering relies on it (otherwise you get a PHP notice)
Revised patch handles these cases.
Comment #3
tim.plunkettThose patches look identical. I like the description in #2 though!
Comment #4
solotandem CreditAttribution: solotandem commentedGood catch. Here is the intended file.
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedThe sanitization can't be removed. In that case, it's a special case. Consider a block which embeds a
<script>
tag. That tag is intended to be rendered and wont' be sanitized out when the block is rendered normally.This tag, however, can completely crash the client parser because that script tag does not expect to be run in isolation, which is what will happen when javascript renders the content. Thus it must not be removed.
Comment #6
merlinofchaos CreditAttribution: merlinofchaos commentedI went ahead and fixed *just* the call to module_invoke because nothing else should hold that up from being fixed.
Comment #8
kaidjohnson CreditAttribution: kaidjohnson commentedSorry to re-open this issue, but the sanitation can throw errors, because some modules' block invocations return a render array for $block->content (i.e. the 'system' block 'main-menu'), which is not the expected parameter type for filter_xss_admin($string). I would propose checking what is the type of $block->content before sanitizing, thus only sanitizing strings. Modules that define their own block render arrays shouldn't (won't?) have problems with <script> tags.
Comment #9
merlinofchaos CreditAttribution: merlinofchaos commentedThe patch is a duplicate. http://drupal.org/node/1925018#comment-7104288
Returning to previous status.
Comment #9.0
merlinofchaos CreditAttribution: merlinofchaos commentedReplace < with [