token_replace by default does a check_plain on the replacement values. The API mentions (and is used as such) that when $strict is FALSE, there is no check_plain run.

The net result is that when using the token values as default form values, double escaping occurs.

CommentFileSizeAuthor
#1 webform-1721996-token-filter.patch522 bytesStevel
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Stevel’s picture

Status: Active » Needs review
FileSize
522 bytes

This patch adds the sanitize option to token_replace to match the value of the $strict variable. When $strict is true, check_plain is used for the token_replace values, otherwise the token replacements are left alone.

quicksketch’s picture

Thanks! Excellent I'll review it when I get a chance.

victoriachan’s picture

Hi,

I have got the same problem where when I use a token (from user profile field) as a default value in a webform form field, the resulting output is displayed with unnecessary check_plain() it seems.

For example, Mum's Shop is displayed as Mum's Shop.

I am using 7.x-3.18, and have applied the patch, but it doesn't seem to make any difference. I don't think it is specific to Profile2 either, as I have tried it using a normal text field as token, and had the same result.

It's tricky to find out what is applying the check_plain() to the token value as it involves so many different modules. I have tried printing the $string variable that is returned from token_replace() in _webform_filter_values(), and the apostrophe has already been encoded as ' then (even when hardcoding the sanitize option as false).

Any idea how I can approach this?

Thanks,
Victoria

quicksketch’s picture

Status: Needs review » Fixed

I am using 7.x-3.18, and have applied the patch

This patch is specifically for the 7.x-4.x branch. I don't think you can pull tokens out of Profile2 in the 3.x version of the module, unless you're using "Webform Patched" module, which is a hacked version of Webform to add token support to the 3.x branch.

I've committed this patch to the 7.x-4.x branch. Thanks @Stevel!

Status: Fixed » Closed (fixed)

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