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

[WordPress Trac]

#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                                   |
-------------------------------------------------+-------------------------
Changes (by hellofromTonya):

 * keywords:  needs-dev-note has-patch has-unit-tests => needs-dev-note has-
     patch has-unit-tests commit


Comment:

 >Escaping the message can lead to some messy messages in log files but I
 think it's safer to presume that the message will be displayed. As the
 message may contain user data then it's best to treat it unsafe.

 The messy messages would be in the browser and log files. Users,
 extenders, and contributors would all experience significantly less
 readable and less understandable messages.

 IMO the messy messages are significantly less readable and understandable.
 They will confuse users, extenders, and contributors, potentially causing
 more investigative and debug efforts.

 Escaping the messages impacts all of Core's messages too, including all
 `_deprecated_*()` and `_doing_it_wrong()` messages. But all of these
 messages are hardcoded, not dynamic. IMO Core itself should be trusted and
 its messages should be readable.

 I do understand your point @peterwilsoncc: to ensure non-Core messages are
 made safe by default within Core. But I think it comes with too hefty of
 side-effect, especially for a potential unknown edge case of a non-escaped
 dynamic message that might have nefarious HTML in it.

 I think the approach taken (i.e. to document extenders need to escape any
 of their messages that have non-hardcoded content) fits well with the
 intent of `trigger_error()`.

 I'll mark [https://github.com/WordPress/wordpress-develop/pull/5175 PR
 5175] for `commit`. But please let's keep discussing. If there's consensus
 to go a different direction, then a follow-up commit can happen.

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