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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

solotandem’s picture

Status: Active » Needs review
FileSize
1.23 KB

Attached patch restores block content display as indicated in issue summary.

solotandem’s picture

Upon 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.

tim.plunkett’s picture

Status: Needs review » Needs work

Those patches look identical. I like the description in #2 though!

solotandem’s picture

Status: Needs work » Needs review
FileSize
1.42 KB

Good catch. Here is the intended file.

merlinofchaos’s picture

The 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.

merlinofchaos’s picture

Status: Needs review » Fixed

I went ahead and fixed *just* the call to module_invoke because nothing else should hold that up from being fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kaidjohnson’s picture

Assigned: Unassigned » kaidjohnson
Status: Closed (fixed) » Needs review
FileSize
597 bytes

Sorry 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.

merlinofchaos’s picture

Assigned: kaidjohnson » Unassigned
Status: Needs review » Closed (fixed)

The patch is a duplicate. http://drupal.org/node/1925018#comment-7104288

Returning to previous status.

merlinofchaos’s picture

Issue summary: View changes

Replace < with [