Hi Jacrobs,

I want to add a link in ALT field, I added Juicebox in ALT field, but It shows html source code.
See below
http://lab.wjguoji.com/node/59

I look at the Juicebox.net demo,it can have a link in alt field.

Juicebox is a free, customizable image gallery. Use it to display your images on any web page in a professional, intuitive and simple way.
Demo below
http://www.juicebox.net/demos/lite/full/#2

Regards,
Tom

Comments

rjacobs’s picture

Title: How can I add a link in ALT field of a Drupal Juicebox gallery » How can I add html to ALT field of a field-based gallery

Hummm, yes are correct that Juicebox supports html in title and caption fields, and this module does its best to ensure that all markup is preserved when it's passed from Drupal to the Juicebox javascript. The trick is making sure that the output is sanitized is some way before display.

When using views, so long as the Drupal field designated as the "caption" field supports html, this html will properly be passed to Juicebox and rendered in the gallery. So for views-based galleries the module leaves it up to views (and the Drupal field system) to sanitize the output, and passes it along directly/untouched.

In the case of galleries based on the field formatter, things are a bit different. In this case the module can only grab these alt/title values in a raw and unsanitized format, and then it must take on the burden of ensuring safe and sanitized output is ultimately displayed. To handle this I was using the same level of sanitizing that Drupal would use if displaying these images normally (without the Juicebox field formatter), which is to pass the values through check_plain(). Of course check_plain() will just turn the output into plain-text, which is ideal for the display of alt/title attributes in a img tag, but maybe not ideal for Juicebox.

I could remove the check_plain() calls, and this issue would go away, but then there would be no sanitizing, which would be bad. So I may need to think of a safe, but less strict, way of filtering the alt/title outputs in this case.

rjacobs’s picture

After some additional thought it's clear that there is not a straightforward solution for this.

The problem is that image fields, unlike normal text fields, do not have any concept of "text format" associated with them. So there is no way to check and capture information about what text format the field author wants to apply to image content or metadata. This also means that there is no point when the author's permission to use various input filters is checked, which is a very important security consideration that Drupal typically enforces while content is being created, as opposed to when it's being displayed.

Though we could simply filter the alt/image values based on the authors "default" text format, that opens up security issues if other users have access to edit the same node. The docs on this page make that clear:

When existing content that does not have an assigned text format needs to be filtered for display, the default text format is the wrong choice, because it is not guaranteed to be consistent from user to user, and some trusted users may have an unsafe text format set by default, which should not be used on text of unknown origin. Instead, the fallback format returned by filter_fallback_format() should be used, since that is intended to be a safe, consistent format that is always available to all users.

So in order to keep in-line with Drupal's security best practices I think it's only safe to use either check_plain() or the site's fallback text format to filter imagefiled alt/title content. Right now we use check_plain() but I'll probably change things to use the fallback text format, as at least that can be configured by an administrator. Once this change is in place it means that the only way to allow html in caption/title values (that use the alt/title attributes of an imagefield) will be to enable markup through the settings on the default (italicized) format at /admin/config/content/formats.

alevelweb’s picture

Hi Rjacobs,

Many thanks for your comments.
I am realy looking forward to that new feature.

Best Regards,
Tom

rjacobs’s picture

Title: How can I add html to ALT field of a field-based gallery » Allow html in ALT field of a field-based gallery
Version: 7.x-1.0-rc2 » 7.x-1.x-dev
Category: support » feature

The following is a related issue that will probably need to be addressed in parallel to this one.

#2049777: Captions and titles should not contain block-level tags (they should be stripped)

rjacobs’s picture

I've made a couple commits recently (notably this one) which should address this and a couple other related things.

As field based galleries now use Drupal's fallback text format for processing titles and captions, admins must allow markup within this fallback text format before any html formatting will work. The fallback text format is the one that's marked with italics at /admin/config/content/formats (for most people it will be the one called "plain text") and is a format that all users have access to. So it's important to remember that anyone who can post content to the site (even cases of anonymous users posting comments, etc.) can use all the options this format allows. This means that admins must be careful when deciding if it's appropriate to go ahead and make this change, as it has potential impacts beyond just the Juicebox module.

If you decide that it is alright to enable markup in your fallback text format click the "configure" link for the it and under "Enabled Filters" uncheck "Display any HTML as plain text" and check "Limit allowed HTML tags" (you can also customize which specific tags are allowed). After this basic markup should start working within field-based gallery titles and captions.

Note that this has no impact on galleries built with the view display plugin, as those use the text format settings of the individual fields that are designated for titles and captions in views.

rjacobs’s picture

Status: Active » Fixed
alevelweb’s picture

Thanks for your comments.
Got it.

Status: Fixed » Closed (fixed)

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