Hi, again i can’t get approval of my theme. Now one of the issues envato team complained is wp_kses(). They say “wp_kses is an expensive function, so it should only be run when data is saved, not displayed. To strip out all HTML tags, you can use wp_strip_all_tags()”
So, i don’t want to strip all the tags. I use this function to cut off all tags except some i want user to be able to use.
They are:
button, form, input, span, div, a, em, i, strong, b, ul, ol, li, img, h1, h2, h3, h4, h5, h6
So when i render something i use that function, in a cople of places, not everywhere. Where header elements are, i want user be able to enter HTML (especially em, strong etc), because creation of all options for any case it’s nightmare and nightmare to use such a continious options list.
It depends on where you’re using it. You have to think about the use-case, however. If you’re using it on large content, sure it will not have good enough performance.
But if you are going to use it on small chunks of text spanning to a few lines at max, then it’s perfectly acceptable to use it when you have to preserve some HTML tags. The performance impact of such usage is negligible. You’re better off optimizing your querying in such a case.
To re-iterate, you can use wp_kses* functions even on the front-end functionality, as long as you don’t over-do it.
The alternative is the violate the suggestion of “always escape late”, and sanitize using wp_kses pre-save via hooks. Personally, I am not a fan of this method and the reviewers will get further confused when you sanitize early. It’s also easy to miss escaping/sanitization when you’re sanitizing early.
It depends on where you’re using it. You have to think about the use-case, however. If you’re using it on large content, sure it will not have good enough performance.
But if you are going to use it on small chunks of text spanning to a few lines at max, then it’s perfectly acceptable to use it when you have to preserve some HTML tags. The performance impact of such usage is negligible. You’re better off optimizing your querying in such a case.
To re-iterate, you can use wp_kses* functions even on the front-end functionality, as long as you don’t over-do it.
The alternative is the violate the suggestion of “always escape late”, and sanitize using wp_kses pre-save via hooks. Personally, I am not a fan of this method and the reviewers will get further confused when you sanitize early. It’s also easy to miss escaping/sanitization when you’re sanitizing early.
Yep i use that to sanitize small pieces of text like.
Italic string
As for early sanitization, i have some problems with that already as well (even in the same file apwards a couple of lines, they say it’s bad ), so i know what you are talking about. Will think about it and read that article.
This allows wordpress to filter your content safely then display html.
Hi, Thank You a lot for sharing your solution. But at the first look it’s not good to me, even worse then it could be with wp_kses(). But it might be that works. Will think about that anyway. Thanks again.
This topic is interesting because I was faced with the same issue a while back for a client’s work where there was a small area (less than 10 words) which had to accept some HTML tags but I couldn’t find a good sanitization function for that.
ThemeProvince said
You can use:
esc_html()
and then decode the html tags to display html using htmlspecialvars_decode()
This allows wordpress to filter your content safely then display html.
I’ve never thought of this solution but does it really filter out the ‘evil code’ in the content? All it does is just to convert the special characters to HTML entities and is reverted back by htmlspecialvars_decode(). So a <script> tag can still be ‘missed’ and executed in this case? Please correct me if I’m wrong.
This topic is interesting because I was faced with the same issue a while back for a client’s work where there was a small area (less than 10 words) which had to accept some HTML tags but I couldn’t find a good sanitization function for that.
ThemeProvince said
You can use:
esc_html()
and then decode the html tags to display html using htmlspecialvars_decode()
This allows wordpress to filter your content safely then display html.
I’ve never thought of this solution but does it really filter out the ‘evil code’ in the content? All it does is just to convert the special characters to HTML entities and is reverted back by htmlspecialvars_decode(). So a <script> tag can still be ‘missed’ and executed in this case? Please correct me if I’m wrong.
Thanks.
Yep, that’s wrong solution. That doesn’t work. Actually it does nothing useful. At first, there is no htmlspecialvars_decode but there is htmlspecialchars_decode, it seems ThemeProvince mentioned that function, or he have his own.
Let’s just check this. Create test.php in the root of your WP folder.