All HTML in 'Global: Custom text' fields is stripped when view style is set to CSV / XML

I have the same problem with any view style.

If i use

<p>
p
</p>

It get's displayed.

Can you describe the kind of html which you use? This problem should be reproducable if it's really a bug

It doesn't work for constructions like this:

<option value="[id]">[title]</option>

or like this (actually it's not HTML at all):

<cities id="[term_id]"><label><![CDATA[ [city] ]]></label></cities>

Am I do something wrong?

Thank you for your replay!

For this textfield the following code is applied

    $value = filter_xss_admin($alter['text']);

So just the following html tags are allowed:

a', 'abbr', 'acronym', 'address', 'b', 'bdo', 'big', 'blockquote', 'br', 'caption', 'cite', 'code', 'col', 'colgroup', 'dd', 'del', 'dfn', 'div', 'dl', 'dt', 'em', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'hr', 'i', 'img', 'ins', 'kbd', 'li', 'ol', 'p', 'pre', 'q', 'samp', 'small', 'span', 'strong', 'sub', 'sup', 'table', 'tbody', 'td', 'tfoot', 'th', 'thead', 'tr', 'tt', 'ul', 'var'

If you needs options of something different you have to use theming of the field.

dereine,

thank you for your replay!
Is it possible to turn filter_xss off?
Is it secure?

No it's not secure to turn of filter_xss. You have to live with this and use real theming if you need such html.

If you install Customfield for views and add a custom field PHP code you will be able to create form elements in it. You can create one PHP field with the starting information like:

 print ("<option value=\"");

and the next one like:

print("</option>");

Exclude both of them.

Than re-write the output in another field so

[phpcode1][id]">[title][phpcode2]

Its a long way around it but it works. I done this when I needed to create a embed code in a form field so users could copy the embed code of a image to paste in their pages.

Hi, is there another workaround for this?

The problem I have is I created a content type with title, body, image and color. The color is suppose to be the background color. So part of the code is something like

But the style gets stripped. I can't add a class for it because the whole point of doing the content type and the view and the custom text was that the background was different for every content.

Any help?

This is the security concept :)

No there is not workaround.

If you really need such html you can use theming of the field.

This is the security concept :)

Who we're trying to protect here?

Creating and managing views are usually done by admins, and I see plenty of ways an ordinary user can use to "attack" a system, if s/he has view admin rights. Just add an argument with a "PHP code" validator and you know what I mean.

So, I fail to see how a XSS filter being run on a field that's supposed to allow the view admin to show any content s/he likes is a security measure. To the contrary, I think that this feature severely limit the usefulness of the "Custom text", which is the first choice when one want to merge several (perhaps hidden) fields on one single field.

Surely, one can always add a template, but I think that for most cases, a template is overkill. For example, I just wanted to group some fields in a fieldset -- a very simple use case -- but got frustated after an hour of research (just to discover in this issue that I was being screwed by this "security feature").

And no, using View Custom Field (VCF) is not a solution. With, VCF if you add a "Markup" field then you get no token replacement. If you add a "PHP Code" field, then all the data you get in the $data variable are unprocessed. Examples, please? Include a Filefield field on your view and all you'll get in the VCF $data variable is the file id (fid) and some exotic serialized PHP array. Link? Icon? Rewitten field content? No way!

How to solve this issue in a compatible way is another question. Perhaps the user may be allowed to choose a input format for this field? Os whould we loose the requirements and allow any HTML and put a big notice on the changelogs?

I just think that this is a real issue and blindly closing it is wrong. This "feature" should be documented somewere, and at least the replacement field description must be changed. Mine today says "The text to display for this field. You may include HTML."

This argument has already been had in the issue queue and we're not having it again. Drupal security standards ask that these fields go through filter_xss_admin() and that's the standard developers are expected to follow. You must use a template.

The End.