Include `htmlspecialchars` in list of escaping functions.

[schlessera]

The PHP function htmlspecialchars is currently not recognized as a valid escaping function.

The function "converts special characters into HTML entities" (http://php.net/manual/en/function.htmlspecialchars.php).

It is actually what esc_textarea() is built upon.

It should be added to the list of escaping functions to be a valid way of getting rid of unneeded "Expected next thing to be an escaping function" errors.

[johnbillion]

What's your use case for using htmlspecialchars() instead of one of the esc_*() functions?

[thenbrent]

@johnbillion we are using htmlspecialchars() one one occasion instead esc_*() because of the issue detailed here: https://github.com/woocommerce/woocommerce/issues/9287

And much more briefly summarised as esc_attr does not double encode here: https://github.com/woocommerce/woocommerce/commit/cf54ea8fc055e079dc956889700af1c7cf614246

[smileBeda]

The question is less what the use case is, and more that it is a valid escaping function inbuilt in PHP.

I would like to add my +1 to this "request".

If anyone is interested in use cases, this particular case involves using WPCS in a project that... is not built on WP. Yes, it is clear to me that WPCS was made and will always be made for and with WP in mind, yet, this is my exact use case :) (which might be argued to be "wrong", but still I would profit from htmlspecialchars being recognised, and agree with @thenbrent that it makes sense to include, unless concerns could be presented to not do so).

[jrfnl]

The WP native escaping functions do more than just escape the special characters, they also check for invalid UTF-8 sequences and potentially apply additional filters.

With that in mind, IMO for text (string) escaping in a WP context, htmlspecialchars() should not be allowed as it is not equivalent to using the WP native esc_*() functions.

For individual cases where you are sure it is the correct way to handle this, you can add a // phpcs:ignore ... comment.