Thoughts on supporting the "double_encode" flag?

[brad-jones]

see: http://php.net/manual/en/function.htmlspecialchars.php

I have a case where I would like to use the double_encode flag.

I understand why you probably don't want to in most cases.
As how would you deal with the following: The HTML entity for "&" is "&".
see: http://stackoverflow.com/questions/16646577/

In my case though I have integrated the Foil view engine into a Wordpress theme.
Foil uses this library for all it's escaping and by default it auto escapes everything, which is great 95% of the time.

There are cases though where Wordpress has already escaped a value, say the "Post Title".
And then foil comes along and escapes again. The solution is to turn off auto escaping and manually escape where needed.

Then I saw the double_encode flag, and figured that would solve my issue.
Went looking for a way to set it through Foil, no dice, then I came here and looked through the source and noticed there is indeed no way to set it.

https://github.com/auraphp/Aura.Html/blob/2.x/src/Escaper/HtmlEscaper.php#L73

If you have strong opinions that the flag is a big NO NO, thats fine however if you think it is something that could be made configurable through your API I will create a pull request for the feature.

Cheers Brad

[harikt]

@brad-jones Sorry for the delay in replying back.

I like the idea regarding turn on / off double encode flag. You can send a PR and hopefully @pmjones will also love I guess. We can merge accordingly.

Thank you.

[mindplay-dk]

FWIW, in my own HTML escape function, I have inline documentation explaining why the $double_encode flag is not exposed and should not be used:

 * If the given content contains HTML-like content, this *will* be double-escaped -
 * in a proper data-flow, your content should never contain already-encoded content,
 * which is why we do *not* offer any means of setting `$double_encode` set to `false`.

Suppressing double encodes causes problems with e.g. & - it's a work-around for a broken data-flow; the correct way to deal with that situation, is to debug your data-flow, rather than patching for partially-encoded (e.g. broken) data at a later stage.

Just my two cents.