Changes between Initial Version and Version 1 of Ticket #17906, comment 3


Ignore:
Timestamp:
03/27/2012 03:05:44 AM (3 years ago)
Author:
PaulM
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #17906, comment 3

    initial v1  
    11The current documented behavior is unfortunate, but firmly entrenched enough that backwards compatibility makes it very hard to just outright change the behavior.
    22
    3 I too would like to see this change happen. I'm marking this ticket as accepted, with the caveat that any solution needs to meet the standard requirements - it's not enough to say "we must change the behavior and break everyone's code". I'd prefer to see a solution that didn't involve adding settings, but that may not be possible.
     3I too would like to see this change happen. I'm marking this ticket as accepted, with the caveat that any solution needs to meet the standard requirements - it's not enough to say "we must change the behavior and break everyone's code". I'd prefer to see a solution that didn't involve adding settings, but that may not be possible. I don't believe the documentation note of "widgets don't escape" is a good reason to keep this behavior as-is.
    44
    55One backwards compatible idea to improve the situation would be to add a warning when these widgets render strings that are not explicitly marked safe. I'd also like to see an easier way for these widgets to optionally escape their output - the recommended format is very clumsy. Perhaps a first step to changing the behavior would be to add a way for template authors to explicitly state which behavior they want. This, combined with a warning when the behavior is not explicit, would pave the way for a deprecation of the existing behavior.
Back to Top