[wp-trac] [WordPress Trac] #57686: Introduce wp_trigger_error() to compliment _doing_it_wrong()
WordPress Trac
noreply at wordpress.org
Wed Sep 13 17:20:10 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 hellofromTonya):
Looking at the balance between message hardening vs readability in a
different way ...
[https://github.com/WordPress/wordpress-develop/pull/5161 PR 5161]
switches `trigger_error()` to `wp_trigger_error()` in `_doing_it_wrong()`
and each of the `_deprecated_*()` functions (in `wp-
includes/functions.php`.
What if those instances don't use `wp_trigger_error()`?
What if instead those instances escape the parts of the message that are
incoming to each function, but don't escape the hardcoded additions to the
message done in each function?
For example, consider `_doing_it_wrong()`. The incoming arguments, i.e.
`$function_name`, `$message`, and `$version`, could be escaped
individually as part of the final message composition. In this way, the
added HTML is not escaped and thus readability is not impacted.
But all messages passed to `wp_trigger_error()` would be escaped.
Could this approach achieve the balance of hardening and readability?
@peterwilsoncc @azaozz @flixos90 @costdev what do you think?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/57686#comment:45>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list