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().

<?php
$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.

Files: 
CommentFileSizeAuthor
#8 ctools-sanitize-strings-only-1587788-8.patch597 byteskaidjohnson
PASSED: [[SimpleTest]]: [MySQL] 121 pass(es).
[ View ]
#4 1587788-update-hook-block-view.patch1.42 KBsolotandem
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1587788-update-hook-block-view_1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#2 1587788-update-hook-block-view.patch1.23 KBsolotandem
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1587788-update-hook-block-view_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#1 1587788-update-hook-block-view.patch1.23 KBsolotandem
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1587788-update-hook-block-view.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new1.23 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1587788-update-hook-block-view.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

StatusFileSize
new1.23 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1587788-update-hook-block-view_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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.

Status:Needs review» Needs work

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

Status:Needs work» Needs review
StatusFileSize
new1.42 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1587788-update-hook-block-view_1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Good catch. Here is the intended file.

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.

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.

Assigned:Unassigned» kaidjohnson
Status:Closed (fixed)» Needs review
StatusFileSize
new597 bytes
PASSED: [[SimpleTest]]: [MySQL] 121 pass(es).
[ View ]

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.

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

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

Returning to previous status.

Issue summary:View changes

Replace < with [