You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
function and block handlers should at least somehow indicate what they are returning, i.e. plain text, html, js, etc.
That way, we would be able to apply auto-escaping when needed and refrain from it when not needed.
Have you considered adding something like SafeString (shamelessly borrowed from Django, https://docs.djangoproject.com/en/4.2/_modules/django/utils/safestring/ ), a small wrapper class around a string to indicate that the user has taken responsibility for escaping, and that the contained string is safe for output?
That would allow a function to indicate that it has taken care of escaping by returning SafeString, or that its output should be escaped (by returning string).
As an added bonus, the same mechanism would also allow for users to supply escaped HTML in normal template variables. So, {$foo} would render <html> when one has done $smarty->assign('foo', new Smarty\SafeString('<html>')). If one instead did $smarty->assign('foo', '<html>'), it would render <html> (as it currently does).
As a secondary bonus, {capture} in templates could use SafeString (as what is captured will have been escaped), which would get rid of needing to use nofilter when one prints captured content.
function and block handlers should at least somehow indicate what they are returning, i.e. plain text, html, js, etc.
That way, we would be able to apply auto-escaping when needed and refrain from it when not needed.
see #906
This also needs to be documented
The text was updated successfully, but these errors were encountered: