Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Reproduce:
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/filefield_handler_field_data.inc, 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?
Comment | File | Size | Author |
---|---|---|---|
#14 | filefield_views2_compatible.patch | 1.53 KB | quicksketch |
#13 | filefield_views2_compatible.patch | 1.52 KB | quicksketch |
#10 | filefield_views_double_encode.patch | 894 bytes | quicksketch |
Comments
Comment #1
Pomliane CreditAttribution: Pomliane commentedSubscribing
Comment #2
suaieru777 CreditAttribution: suaieru777 commentedSubscribing... 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
Comment #3
mattiasj CreditAttribution: mattiasj commentedsame issue here, is there any workaround?
Comment #4
gjones CreditAttribution: gjones commentedI 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?
Comment #5
cmsproducer CreditAttribution: cmsproducer commentedMost/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
Comment #6
FrankzeTank CreditAttribution: FrankzeTank commentedHere 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:
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.
Comment #7
jrockowitz CreditAttribution: jrockowitz commentedBoth the above solutions work but I would recommend not using htmlspecialchars_decode() because it will also convert < and > 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('&', '"', '''), array('&', '"', "'"), $value); which will only convert &, " and ' back to &, ", and '.
So, for solution #4 the change would be
Comment #8
FrankzeTank CreditAttribution: FrankzeTank commentedThanks 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:
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.
Comment #9
jrockowitz CreditAttribution: jrockowitz commentedYou 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.
Comment #10
quicksketchI've committed this patch to correct this issue. It will be included in the 3.10 version.
Comment #11
whitelancer CreditAttribution: whitelancer commentedHey 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?
Comment #12
quicksketchOh hmm, perhaps that is a Views 3 method. I'll investigate using a simpler approach.
Comment #13
quicksketchYep, 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.
Comment #14
quicksketchBah, missed a line that should be removed. This patch takes the place of the previous one.
Comment #15
quicksketchFixed and tested with Views 2. The 3.10 version of FileField is now available for your downloading pleasure.