-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
transform.Plainify should return template.HTML instead of a string #8732
Comments
You should open that in the discourse instead of here. Regarding the issue at hand: I think it's because of the security model of Golang templates. Go expects the developer to make everything safe, so plainify can't just do an html unescape or mark the string as safe. I think it was recently only that script and style tags were removed by plainify. Lot's of hijinks would have been possible if Go just assumes that the string is safe. See here: https://golang.org/pkg/html/template/#hdr-Security_Model (the whole chapter is an interesting read) |
Yes I don't like the safeHTML either, maybe to include htmlUnescape would be safer and useful. What is the current use case for plainify? In my code 100% of my plainify calls have to be followed by one of the other filters. Maybe there should be a new method to extract plain text from html and return it as unescaped string rather than messing with plainfy. |
These transformation functions return
I think it makes sense to add |
None of these are useful as plain strings in the templates, which forces the users to do `transform.Plainify "foo" | safeHTML`. If people have trust issues with the output of these functions, they need to just stop using them. Closes gohugoio#8732
None of these are useful as plain strings in the templates, which forces the users to do `transform.Plainify "foo" | safeHTML`. If people have trust issues with the output of these functions, they need to just stop using them. Closes gohugoio#8732
None of these are useful as plain strings in the templates, which forces the users to do `transform.Plainify "foo" | safeHTML`. If people have trust issues with the output of these functions, they need to just stop using them. Closes gohugoio#8732
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
What version of Hugo are you using (
hugo version
)?Does this issue reproduce with the latest release?
This is the latest release.
When using
plainify
hugo many times does the wrong thing. I realize that this is a feature, but I wonder if there is a better way to do it. Specifically, if the HTML contains any HTML entitiesplainify
returns the plain HTML with the entities but not marked as a HTML safe string. So theplainify
output for HTML like<div>This & that</div>
will beThis & that
. Now it's easy to pipe it throughsafeHTML
ormarkdownify
orhtmlUnescape
to solve the problem, but it seemsplainify
should probably include an automatichtmlUnescape
or at least mark the output as HTML safe.This is a petty kind of thing, but in our code, we always must do
plainify | htmlUnescape
and whenever we forget it the entities are shown on the screen. Seems cumbersome.The text was updated successfully, but these errors were encountered: