What all gets run on post_contentwhen saving to the database? I all I can seem to find is wp_filter_post_kses( $value );

Sanitizing wp_editor(); Values for DB, Edit, and Display Free reputation if anyone wants to answer.

@TomJNowell Thanks for your answer. Is there anything wrong with my approach?

It appears to work for me.

I dont see the need for the wpunslash etc

wp_kses_post does just fine

also sanitize_post_field is a sanitising function, not an escaping function

Why is there an option for "display" then?

and I added wp_unslash(); because it was slashed after retrieving it from the database. wp_filter_post_kses(); slashes.

What should I use to escape then? I want it to behave exactly as it would if you were to display the post_content.

I don't see the need for either, sanitize_post_field() calls wp_kses_post when called in a DB context.

@MichaelEcklund in practice and in code review I have never encountered the sanitise_post_field function, and i'm suspicious of it

@Howdy_McGee okay maybe I should've put an asterisk in there. Not 100% exactly like post_content, I don't want to run the_content filter on there, because it's not "the main content".

so maybe what ever callbacks are fired on the_content might be wise to also fire on my value?

minus what possibly other plugins might be adding to the_content filter

@TomJNowell Are you advising to literally just use echo wp_kses_post( $value ); for output then?

@MichaelEcklund yes

wp_editor will do its own internal escaping etc

for editing?

and on output you want an escaping function or wp_kses_post

wp_editor is responsible for the output, let it do its job

ok

don't try to be unhelpfully helpful by pre-escaping

ok

wp_editor does its own escaping

wp_kses_post can also be used to sanitize

so what would I use to escape the value for output then

as it strips out the illegal tags

wp_kses_post

see the answer I wrote, it covers output and escaping

but a general rule of thumb, is that if you're escaping with a function that says sanitize, something has gone wrong

@TomJNowell Oh I'm sorry you said "OR" not "FOR". I read that wrong.

ok thanks

also keep in mind that escaping is context dependent

hence the other parts of my answer

aka attributes use esc_attr, URLs use esc_url, etc

you should edit your answer to clarify the wp_editor does escaping, don't be unhelpfully helpful

and your general rule of thumb tip might be a good thing to include as a footnote maybe

if a function outputs internally, it's responsible for its own escaping

i like that too, you should add that as well

you will have a rock solid answer

done, remember, escape often, escape late

at the very last moment possible

@MichaelEcklund Just like any other filter it's purpose is broader than the main post content. It'll allow you to process shortcodes and such.

if you're having to escape something and return it as a string then, nope, game over, you're dead, they broke through

the only exceptions are places were core prevents you from following good practice, in which case you have the concept of trusted filters

e.g. we have to trust shortcodes are implemented properly, and that everything that hooks into the_content escapes and sanitises anything it adds correctly

Why would you need to use wp_post_kses() on the way in and out? Wouldn't on the way in suffice?

because you can't trust what might have happened to the content in transit

a function might have appended something, or modified something

or it might have been changed in the DB

or adjusted by filters

wp_kses_post and the wp_kses family are the only functions you can use that way, as you can call them repeatedly on the same output without changes

technically, it isn't an escaping function, but it serves the purpose of one

Couldn't you say that about any of the WordPress functions though? For instance, if I call the_content() in the loop the same issues you've described could happen.

the_content escapes internally, the only issue is the_content filter, hence trusted filters

it's suboptimal ofcourse, but we're stuck with it

think of it this way, you do QA on the finished result, you don't repeatedly test the end product as if it were finished throughout the production process

that's what assertions and validators are for

so we escape right at the very end

In the example in your answer it seems to me we're re-sanitizing what's returned from the database, then passing that into filters which could modify the re-sanitized result.

I guess it's a very defensive approach but it seems unnecessarily so.

not really, anything could have happened between when it was fetched from the DB and when it was output

we don't know, nor should we have to

if it was fetched from the DB and immediatley ran through wp_kses_post, that'd be early escaping which is bad

but keep in mind that on the way in it's being used as a sanitizer, on the way out it's being used as an escaper