[wp-trac] [WordPress Trac] #57686: Introduce wp_trigger_error() to compliment _doing_it_wrong()

WordPress Trac noreply at wordpress.org
Thu Sep 7 21:01:08 UTC 2023


#57686: Introduce wp_trigger_error() to compliment _doing_it_wrong()
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:
                                                 |  hellofromTonya
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.4
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-dev-note has-patch has-unit-   |     Focuses:
  tests commit                                   |
-------------------------------------------------+-------------------------

Comment (by flixos90):

 @hellofromTonya Regarding the escaping, my 2 cents is that we should
 **avoid escaping in these functions entirely**, for the following reasons:

 * None of these functions have historically escaped their messages, and
 given this was never raised as a problem (as far as I'm aware) I'm not
 convinced now is a good reason to start auto-escaping.
 * Automatically escaping, as great as it would be if possible, is
 unreliable, as we can tell from this alone. Escaping is not a "one size
 fits all" thing: Sometimes it is about escaping all HTML (`esc_html()`),
 while other times it is about stripping all HTML except a certain set of
 tags or attributes (see `wp_kses()`).
 * Other related functions like `wp_die()` do not automatically escape
 either, instead developers should escape the content that they pass to it
 as needed.
 * `trigger_error()` does not escape what is passed to it, so why should
 `wp_trigger_error()` do so? I think that mixes up responsibilities, in
 addition to the above problems.

 While it would be great if somehow WordPress core could automatically
 escape anything anywhere, in reality this is something that is
 responsibility of the individual developer since in most cases it can't be
 centrally handled. We already have WordPress coding standards that flag
 any missing escaping, and I think we should continue to rely on those.

 So I think we should remove the `esc_html()` call from
 `wp_trigger_error()`.

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


More information about the wp-trac mailing list