-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move html into templates #1272
Move html into templates #1272
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see why this is an improvement. And removing the raw
filters should prevent problems in the future with the cases that are not causing any problems right now.
However we are losing quite some markup this way. If that is acceptable. I'm fine with this too. But we could also think of a way to make the raw filter more safe. For example by providing a safer blacklist (scrapping the script tags and other possible xss avenues).
After seeing that we are losing many <p>
wraparounds, I stopped 1 by 1 checking each of them. So be warned there.
...base/templates/modules/Authentication/View/IdentityProvider/perform-request-access.html.twig
Outdated
Show resolved
Hide resolved
...templates/modules/Authentication/View/Feedback/authn-context-class-ref-blacklisted.html.twig
Show resolved
Hide resolved
...templates/modules/Authentication/View/Feedback/authn-context-class-ref-blacklisted.html.twig
Show resolved
Hide resolved
...base/templates/modules/Authentication/View/Feedback/authorization-policy-violation.html.twig
Show resolved
Hide resolved
theme/base/templates/modules/Authentication/View/Feedback/missing-required-fields.html.twig
Show resolved
Hide resolved
85d10c9
to
7250502
Compare
An error message is now wrapped in <p> tags if there are multiple paragraphs, not otherwise. This was done inconsistently before. It does not impact the display of said messages.
7250502
to
b444b40
Compare
I've checked the I've checked and there's no objection to the small loss of markup. Where there was potentially bigger loss I've already solve that in moving the HTML into the templates. Overall I think it's essential that in EB we reduce risk and complexity where we can and make frameworks work for us. So when in doubt I chose the less complex approach of just not using HTML in a translatable string. |
Robustify the templating by moving HTML from translatable strings into the Twig templates. This also allows us to reduce the amount of
|raw
Twig filtering we use, the vast majority of templates do not use|raw
anymore now.This may not be fully backwards compatible: those with language string overrides for the affected strings, or with templates based on the changed strings, may need to make updates.