Hi,

I want to show the term description at top of a panel, which works well so far. But I can't use custom html-filters / no filters for this code. I use tinyMCE and extended html-code like image maps for creating the term descriptions, but the output of the term description content by panels 2 is always standard filtered html without some extended html-tags. How can I modify this to output the code without filtering ? In my opinion it is a bug and should be fixed because the type of input-filter is applayed during editing.

Thanks & full respect for this excellent module
Jürgen Brocke

Comments

sdboyer’s picture

sdboyer commented
Status: Active » Closed (won't fix)

Thanks :)

Unfortunately, there are a lot of potential security concerns with allowing the titles to pass through unfiltered, particularly because of the enormous number of different places those titles can end up being derived from. Figuring out a way to safely allow this to happen from within the Panels interface just isn't feasible. It's not even advisable to simply put a checkbox in that disables filtering in just one situation, as it makes it far too easy for non-super-expert site admins to open up a serious security hole in their site without being fully aware that they're doing so.

humanoid’s picture

humanoid commented

Hi sdboyer,

thanks for your answer.
I'm not sure we are talking about the same thing. I wanted to output the term description (not title) as it was input and according to the selected filter at the input-field. So If I allow "HTML" at the input field for the term description, I should be able to output that code at the panel content "term description". Am I wrong ?

But for me now I found the solution:

in file modules/panels/content_types/term_description.inc Line 33
I changed from
$block->content = filter_xss_admin($term->description);
to
$block->content = $term->description;

That's what I was looking for.

best regards
Jürgen

sdboyer’s picture

sdboyer commented

Sorry, it looks like I did misread your original issue. The same general principle still applies, but I'm glad you found a solution. As long as you're aware, that is, that we consider where we put those calls to filters pretty carefully, and you may be opening up some security holes by making that change...