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.Follow-up to #2307053: Rotate effect UI does not allow to set background color to transparent and #1825952: Turn on twig autoescape by default.
In testing #2307053: Rotate effect UI does not allow to set background color to transparent it was discovered that #1825952: Turn on twig autoescape by default had introduced a double escape in the rotate form and summary theme as well. The degrees character (°) shows up as °
Proposed resolution:
Do not use the html entity but use the UTF character for degrees.
| Comment | File | Size | Author |
|---|---|---|---|
| deg.patch | 1.37 KB | fietserwin | |
Comments
Comment #1
fietserwinComment #2
fietserwinComment #3
mondrake#1938910: Convert image theme tables to table #type, now RTBC, fixes the issue on the image effects table, so the change in the Twig template is not necessary once that's in.
That would leave the change on the field suffix of the form - no idea whether it's better to change to the single UTF-8 char like the current patch, or rather use the brand new 'inline_template' #type à la #2289999: Add an easy way to create HTML on the fly without having to create a theme function / template.
In general it seems to me we are avoiding to use directly single UTF-8 chars where we have html equivalents, see also as an example #1912608: Update pagination markup for new CSS standards and improved accessibility for the use of
…instead of the ellipisis char '…'Comment #4
fietserwinThe last issue you mention does not convince me that Drupal in general is avoiding the use of utf8. They are doubting it and chose to reduce translation work by keeping existing strings.
In contrast, looking around in the code, I see e.g. use of « and similar characters both for pager and Views' own pager. IMO html entities are a relic of the old days where we had no standard for those special characters. now we have 1 encoding: utf-8. Moreover they are html specific and will fail in a non-html environment and will fail in environments where too much escaping is done. So this whole problem could have been prevented in the first place by using the unicode characters.
Note even with the first 2 issues you mention, this patch still will remove the problem and prevent it in the future and thus can be committed alongside and independent of those other issues.
So for now, I leave the patch as is, setting back to NR to get more reactions.
Comment #5
aneek CreditAttribution: aneek commentedI don't think using degrees character (°) like this is always a good idea. Instead we have to use
°. I am sure this is an issue related to#field_suffix&#field_prefix. These two can't handle HTML properly, it double escapes the HTML. Once the issue with#field_suffix&#field_prefixgets fixed we can use proper HTML there. Till then I think we should hold this one.Comment #6
fietserwinI really don't get what is wrong with directly using the degrees character, or for that matter, any "special" character. Can anyone explain?
That some parts of Drupal gets escaped twice is indeed an error, but one that unnecessarily shows here.
Comment #7
RainbowArrayI asked chx on IRC, and he thought UTF-8 characters are allowed as well.
However, since at least part of this is a #suffix issue, that part may be solved by: #2324371: Fix common HTML escaped render #key values due to Twig autoescape.
Comment #8
fietserwinI agree that it is a bug due to the autoescape feature and that the other issue should solve that more generally. So I'm changing this issue into a feature request/task, as in my opinion it is better to stay away from html entities as much as possible as we cannot always be sure in what contexts a text will be used.
Comment #9
RainbowArrayComment #10
Damien Tournoud CreditAttribution: Damien Tournoud commentedIt's actually much better to avoid HTML entities as much as possible, because they force you into an HTML context, while straight Unicode characters work for both plain-text and HTML. Since at least Drupal 6 we go for the Unicode character as a rule.
Comment #12
mondrakeSo based on #10 this is RTBC. Tested manually on simplytest.me
Comment #13
alexpottCommitted cd65494 and pushed to 8.0.x. Thanks!
Comment #16
jibran