Create a cck filefield or imagefield with enabled file descriptions.
Create a view to show file descriptions.
Create a node with a filefield, and in the description field, enter something with ampersand or quote.

When I enter something like "Mom & Dad", or "Mom's recipes" as a description, I get "Mom & Dad" and "Mom's recipes"

In views/, the render function gets this value from the function filefield_data_value, which passes it through check_plain. Is this a double check_plain issue?

Members fund testing for the Drupal project. Drupal Association Learn more


Pomliane’s picture


suaieru777’s picture

Subscribing... exactly same thing happened to my site. It started to happen after I updated Filefield/ImageField from 6.x-3.7 to 6.x-3.9

Drupal core 6.20
Content Construction Kit 6.x-2.9
FileField 6.x-3.9
ImageField 6.x-3.9
Views 6.x-2.12
Skinr 6.x-1.6
Fusion 6.x-1.0

mattiasj’s picture

same issue here, is there any workaround?

gjones’s picture

I ended up having to add htmlspecialchars_decode() to views/

Anyone know how to implement this into the template.php so I don't have to worry about updates saving over my quick and dirty change?

function render($values) {
    $values = drupal_clone($values); // Prevent affecting the original.
    $data = unserialize($values->{$this->field_alias});
    $values->{$this->field_alias} = filefield_data_value($this->options['data_key'], $data[$this->options['data_key']]);
	return htmlspecialchars_decode(parent::render($values));
    /*return parent::render($values);*/
cmsproducer’s picture

Issue tags: +unicode

Most/all the functions in that file do not seem to have been written as themeable functions. They can be tweaked to make them themable -, but then that will make it a quasi-custom module and thus defeat the purpose of keeping the changes out of the update stream for this module.

Personally, I have opted to continue running 6.x-3.7 for the time being/until a fix is available officially. Especially since 3.9 does not have any security patches relative to 3.7, the update is just a "nice to have" and so not worth the problem of having encoded characters all over the place

FrankzeTank’s picture

Here is one Hack that I'm using to get by until it's fixed using View php custom field module.

Read up on Php customfield module if you need help with the snippet below but it's pretty basic php. Just insert it into your custom php view field. Please note: You need to find your field name using dsm($data); with devel enabled and replace node_data_field_article_image_field_article_image_data with your field name .

In my case:

$desc = $data->node_data_field_article_image_field_article_image_data;
$desc = unserialize($desc);
$desc= $desc['description'];
$field_desc = htmlspecialchars($desc);
echo $field_desc;

All you are essentially doing in this case is escaping everything one time from the raw description field in this case. The only problem with doing htmlspecialchars_decode() as mentioned in #4 is that if you forget about this in your theme when this eventually gets fixed it will create a security hole as it will essentially translate the escaped characters back into normal form again. Hope it helps, and I hope this gets fixed soon.

jrockowitz’s picture

Both the above solutions work but I would recommend not using htmlspecialchars_decode() because it will also convert &lt; and &gt; back to < and > which will then be interpreted as HTML tags and even script tags, exposing your website to easily exploited XSS attacks.

Instead use str_replace(array('&amp;', '&quot;', '&#039;'), array('&', '"', "'"), $value); which will only convert &amp;, &quot; and &#039; back to &, ", and '.

So, for solution #4 the change would be

function render($values) {
    $values = drupal_clone($values); // Prevent affecting the original.
    $data = unserialize($values->{$this->field_alias});
    $values->{$this->field_alias} = filefield_data_value($this->options['data_key'], $data[$this->options['data_key']]);
    return str_replace(array('&amp;', '&quot;', '&#039;'), array('&', '"', "'"), parent::render($values));
    /*return parent::render($values);*/
FrankzeTank’s picture

Thanks for the alternative solution, it's always better to have options, but I don't think what you said about htmlspecialchars() is correct. I tried both out and all it seems to do is to escape all characters. It doesn't reconvert them back again as mentioned.

Here is the code used to test claim:

$a = htmlspecialchars('&lt;');
$a = htmlspecialchars('<');

Devel Results



It just escapes it twice if you have < as seen. Which is the whole issue this thread is about. LOL. But if what I said is incorrect, please correct me.

jrockowitz’s picture

You are right. I meant to say in previous comment that htmlspecialchars_decode could expose you to XSS. I corrected my original post.

Thanks for catching that.

quicksketch’s picture

Status: Active » Fixed
894 bytes

I've committed this patch to correct this issue. It will be included in the 3.10 version.

whitelancer’s picture

Hey Quicksketch,

I just tried your patch out on the latest cck/filefield/etc, and I'm getting this error:

Fatal error: Call to undefined method filefield_handler_field_data::get_value() ...

I am trying to use this in returning the caption/description for image fields. The only place I see the function get_value is for views/handlers/ Of course this isn't an argument, it's a field -- so I'm not sure the best solution here.


quicksketch’s picture

Oh hmm, perhaps that is a Views 3 method. I'll investigate using a simpler approach.

quicksketch’s picture

Yep, get_value() only exists in Views 3. Thanks for the nice catch! This approach is the one supported by both Views 2 and Views 3. I've committed it (on top of the existing patch which has already been committed.

quicksketch’s picture

Bah, missed a line that should be removed. This patch takes the place of the previous one.

quicksketch’s picture

Fixed and tested with Views 2. The 3.10 version of FileField is now available for your downloading pleasure.

Status: Fixed » Closed (fixed)
Issue tags: -unicode

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