KSES: Deprecate wp_kses_stripslashes

[jonsurrell]

​wp_kses_stripslashes() does not appear to have a purpose in modern PHP. Documentation suggest that it was required to support the e eval regular expression flag:

This function changes the character sequence \" to just ". It leaves all other slashes alone. The quoting from preg_replace(//e) requires this.

Some historical context from @duck_ supports this (bold mine):

wp_kses_stripslashes is a legacy function that had to be used to deal with addslashes() run when using preg_replace() and the eval modifier. The double quotes remained slashed because the backreference in the PHP string to be evaluated was in single quotes, so a custom slash removal function was used to remove slashes from in front of double quotes.

I would prefer to actually remove the call as it's no longer necessary. If you're passing slashed data to kses it should be stripped first -- which is why we do stripslashes in wp_filter_kses(). Unfortunately removing the call would cause breakage for those passing in slashed data containing double quoted attributes as this happens to work at the moment.

There is a potential problem mentioned that should be better understood before proceeding.

---

​The flag was removed in PHP 7, so the e flag is not supported by any PHP version that WordPress supports. wp_kses_stripslashes() is likely obsolete.

There was work to remove the e flag usage 16-17 years ago:

• [10339]
• [12198]

Related tickets:

• #19877
• #56118

The function may be doing more harm than good at this point. See ​Gutenberg 6619 and ​Gutenberg 16508.

Trac ticket: https://core.trac.wordpress.org/ticket/63881

​wp_kses_stripslashes() does not appear to have a purpose in modern PHP. Documentation suggest that it was required to support the e eval regular expression flag:

This function changes the character sequence \" to just ". It leaves all other slashes alone. The quoting from preg_replace(e) requires this.

Some historical context from @duck_ supports this (bold mine):

wp_kses_stripslashes is a legacy function that had to be used to deal with addslashes() run when using preg_replace() and the eval modifier. The double quotes remained slashed because the backreference in the PHP string to be evaluated was in single quotes, so a custom slash removal function was used to remove slashes from in front of double quotes.

I would prefer to actually remove the call as it's no longer necessary. If you're passing slashed data to kses it should be stripped first -- which is why we do stripslashes in wp_filter_kses(). Unfortunately removing the call would cause breakage for those passing in slashed data containing double quoted attributes as this happens to work at the moment.

There is a potential problem mentioned that should be better understood before proceeding.

​The flag was removed in PHP 7, so the e flag is not supported by any PHP version that WordPress supports. wp_kses_stripslashes() is likely obsolete.

There was work to remove the e flag usage 16-17 years ago:

[10339]
[12198]
Related tickets:

#19877
#56118

The function may be doing more harm than good at this point. See:

• ​https://github.com/WordPress/gutenberg/issues/6619
• ​https://github.com/WordPress/gutenberg/issues/16508

[dmsnell]

The logic seems sound and I like the combination of deprecating and trying to prevent further corruption.

Are we introducing any changed or new behaviors by trying to avoid double-stripping? I don’t have any good bearing on how this could go wrong?

For instance, do we know of any current workarounds to the Core behavior? Was there a case that brought this to your attention? I guess it was the issue with block attributes ending in /?

[jonsurrell]

Are we introducing any changed or new behaviors by trying to avoid double-stripping? I don’t have any good bearing on how this could go wrong?

I think you saw ​KSES: Prevent stripslashes from stripping escaped slashes which is an unlinked draft PR. I think that fixes a problem with unescaping quotes that are not escaped, but it's hard to know whether it fixes something because the purpose and desired behavior of the function are so unclear.

​KSES: Deprecate wp_kses_stripslashes is the PR that deprecates and stops using wp_kses_stripslashes() in Core. That does introduce a potentially more significant change in behavior. It's hard to know how relevant that is but it's what @duck_ mentioned years ago:

Unfortunately removing the call would cause breakage for those passing in slashed data containing double quoted attributes as this happens to work at the moment.

---

Do we know of any current workarounds to the Core behavior?

I'm only aware of the block editor example below.

Was there a case that brought this to your attention? I guess it was the issue with block attributes ending in /?

Yes, for me this started with ​https://github.com/WordPress/gutenberg/issues/6181 and subsequently ​https://github.com/WordPress/gutenberg/pull/6619. Those reference wp_kses_stripslashes() as problematic and introduced a solution with its own problem of not being able to end an attribute values in \ (#63917).

I've proposed fixes for the \ problem:

• ​https://github.com/WordPress/gutenberg/pull/71291
• ​https://github.com/WordPress/wordpress-develop/pull/9558

I believe that specific case is safe from wp_kses_stripslashes() now, but it's such a