Views file data description shows encoded characters

Subscribing

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

same issue here, is there any workaround?

I ended up having to add htmlspecialchars_decode() to views/filefield_handler_field_data.inc

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);*/
  }

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 -http://drupal.org/node/165706, 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

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:

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

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('&', '"', '''), array('&', '"', "'"), parent::render($values));
    /*return parent::render($values);*/
  }

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('<');
dsm($a);
$a = htmlspecialchars('<');
dsm($a);

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.

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.

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

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/views_handler_argument.inc:712. Of course this isn't an argument, it's a field -- so I'm not sure the best solution here.

Thoughts?

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

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.

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

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