According to the documentation, the |shortcodes Twig filter is intended to use shortcodes in Twig templates. However, it will never work without also using the |raw filter because Twig will escape all HTML markup (with either &XX notation or with double quotes around the expanded string).
Since the shortcodes (almost?) always imply generating some HTML, it actually makes no sense to use them without the |raw filter in Twig — nothing will work. And this is not even mentioned in the README.
How to reproduce:
Just put something like
{{ '[fa=cog /]'|shortcodes }}somewhere in e.g. base.html.twig. This will generate the following "broken" HTML (that will be rendered as HTML source instead of a FA icon in this example):
<i class="fa fa-cog"></i>
If used with |raw like this:
{{ '[fa=cog /]'|shortcodes|raw }}it will generate the correct output that renders the icon properly:
<i class="fa fa-cog"></i>
Perhaps, if, for some reason, keeping the current behavior is needed (though I can't come up with such a use case), a new filter shortcodes_raw may be introduced (and documented in README). However, I think it really makes sense to just always pipe |shortcodes output via |raw internally.
According to the documentation, the
|shortcodesTwig filter is intended to use shortcodes in Twig templates. However, it will never work without also using the|rawfilter because Twig will escape all HTML markup (with either&XXnotation or with double quotes around the expanded string).Since the shortcodes (almost?) always imply generating some HTML, it actually makes no sense to use them without the
|rawfilter in Twig — nothing will work. And this is not even mentioned in the README.How to reproduce:
Just put something like
{{ '[fa=cog /]'|shortcodes }}somewhere in e.g.
base.html.twig. This will generate the following "broken" HTML (that will be rendered as HTML source instead of a FA icon in this example):If used with
|rawlike this:{{ '[fa=cog /]'|shortcodes|raw }}it will generate the correct output that renders the icon properly:
Perhaps, if, for some reason, keeping the current behavior is needed (though I can't come up with such a use case), a new filter
shortcodes_rawmay be introduced (and documented in README). However, I think it really makes sense to just always pipe|shortcodesoutput via|rawinternally.