[wp-trac] [WordPress Trac] #57686: Introduce wp_trigger_error() to compliment _doing_it_wrong()
WordPress Trac
noreply at wordpress.org
Wed Sep 13 18:16:35 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 costdev):
> Could this approach achieve the balance of hardening and readability?
I believe so, provided that we choose the right escaping function. I don't
believe `esc_html()` is the right one for these functions.
Core uses `<code>`, `<strong>` and `<a>` in `_doing_it_wrong()`,
`trigger_error()` and similar.
[https://wpdirectory.net/search/01HA7VB2ZWXX2CPJF2TK0W5DX4 Plugins] and
[https://wpdirectory.net/search/01HA7VKXWNR06XAB87JAY91E0X Themes]
typically use `<code>`, `<strong>` and in some cases `<br>`.
We could either allow a limited number of tags with:
{{{
wp_kses(
$message,
array( 'code', 'strong', 'br', 'a' => array( 'href' ) ), //
$allowed_html
array( 'http', 'https' ) // $allowed_protocols
);
}}}
or discourage the use of HTML in these messages - though this would remove
`<a>` included in both Core and extender calls, and `<br>` where some
formatting may be desired when displayed as a UI message.
@flixos90 Do you think supporting `<code>`, `<strong>`, `<a href>`,
`<br>`, and possibly `<em>` could work to cover the vast majority of
cases?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/57686#comment:47>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list