Closed (fixed)
Project:
Chaos Tool Suite (ctools)
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
4 May 2010 at 16:18 UTC
Updated:
1 Jun 2010 at 00:40 UTC
Jump to comment: Most recent file
Comments
Comment #1
merlinofchaos commentedNo, the choice to use filter_xss_admin is intentional so that administrators can put HTML in their block titles. Likewise, there is even a comment explaining why strip_tags is used over check_plain(). Brazenly deleting that comment without any explanation of why that comment is inaccurate is not going to be accepted.
Comment #2
c960657 commentedI guess my initial bug report wasn't very elaborate :-) I'll try to explain the problem in more detail. Also, I have updated the patch with some more comments.
HTML in block titles is not supported by Drupal core. What is saved to {block}.title is considered plain text and core always passes the string through check_plain() when it is displayed.
If you create a block and add it to a region on the page using admin/build/block, the block title and block description is passed through check_plain() when the block is displayed by core. E.g. if the block title and block description are set to "About the <br> tag" (i.e. the block contains a short HTML tutorial), this text is what users will see in the list on admin/build/block and on the frontend site.
Now, if you add the same block to a page using Panels, the title is not escaped, so the users will see text "About the tag" with a line-break in it. I.e. the block will have a different title depending on whether it is inserted as a regular block or via Panels.
Using blocks and panels on the same page may be unusual, so - strictly speaking - you could say that Ctools could redefine the meaning of block titles and block descriptions (though I wouldn't recommend this approach). However, this does not apply to blocks created by other modules than core's block module. hook_block() is defined so that $block['info'] is considered to be a plain-text string. Modules expect this to be passed through check_plain() on display. Modules implementing hook_block('list') are not required to be aware of Ctools, so they don't know that Ctools expects them to pass the string through check_plain() themselves.
Even with the patch, the user can still override the title from block defined by the block module using the override_title feature in Ctools. Also, the patch doesn't prevent modules (other than the block module) from returning HTML in $block['subject'] in hook_block('view').
In conclusion, I think there are two related problems:
1. Modules expect $block['info'] to be plain text, so this should always be passed through check_plain() by Ctools.
2. The block module itself considers {block}.title to be plain text, though Ctools could redefine the meaning of this, though with some surprising result (the displayed title depends on how the block is inserted).
I think no. 1 is a bug, but I guess you could argue that no. 2 is by design.
Comment #3
merlinofchaos commentedI'm a bit dubious. I know I had a reason for that strip_tags, but my research suggests it goes all the way back to the very original implementation of Panels and I think that there was a double check_plain() going on. So with some good testing, maybe.
However:
That changes behavior and causes $conf['override_title'] to be ignored. This is bad behavior. override_title is an override and should always be respected.
Comment #4
c960657 commentedSorry, that was actually a separate issue I discovered while testing the patch. AFAICT override_title is handled in ctools_content_render(). The change seems necessary in order to use the %title placeholder in the overridden title.
Comment #5
merlinofchaos commentedHmm. But that ends up forcing a query when it may not be needed. Panels prides itself on adding as few extra queries as possible.
Comment #6
c960657 commentedNow the title look-up is skipped, if the title is overridden and does not use the %title placeholder.
Comment #7
sdboyer commentedLatest patch has it all covered, so committed. Thanks!