[wp-trac] [WordPress Trac] #62619: Remove `wp_kses_post()` filtering from admin notices

[WordPress Trac]

#62619: Remove `wp_kses_post()` filtering from admin notices
----------------------------+---------------------
 Reporter:  azaozz          |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  6.8
Component:  Administration  |     Version:  6.4
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+---------------------

Comment (by joedolson):

 Passing along some thoughts from @costdev, as the original author; I'll
 follow up with my own thoughts, after.

 ======


 Whether the original intent of `wp_kses_post()` was only to sanitize
 before being sent to the database,
 [https://github.com/search?q=repo%3AWordPress%2Fwordpress-
 develop+wp_kses_post&type=code Core],
 [https://developer.wordpress.org/apis/security/escaping/ DevHub],
 [https://github.com/WordPress/WordPress-Coding-Standards/issues/1270
 WPCS], [https://docs.wpvip.com/security/validating-sanitizing-and-
 escaping/#wp_kses WPVIP] all clearly either use or advise the use of
 `wp_kses(_post)()` when escaping output containing HTML. Original intent
 aside, the wide range of the above references clearly demonstrates a
 different understanding and usage in real-world scenarios.

 It's not only user input to be escaped, but also error responses from
 external requests that may require escaping before output.

 Requiring core and plugin authors to handle escaping themselves by
 default, rather than by exception, goes against the well-established
 practice of late escaping. It would also make filtering arguments and
 markup quite difficult.

 The action isn't likely to appear in many public plugins. We always
 primarily intended it to be useful in cases such as logging fired admin
 notices.

 There's ultimately no need to deprecate `wp_admin_notice()` or to change
 its established use of `wp_kses_post()` in line with well established
 convention in and out of core. If it's not suitable for a particular use
 by core or an extender, they can use `wp_get_admin_notice()`. At most,
 maybe a `$sanitize_callback` parameter could be added, but to my
 recollection, this is mostly seen in the REST API and would be a unicorn
 parameter in the context of admin notices/general HTML output.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62619#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform