[wp-trac] [WordPress Trac] #57686: Introduce wp_trigger_error() to compliment _doing_it_wrong()
WordPress Trac
noreply at wordpress.org
Wed Sep 13 20:59:09 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):
I think the approach @costdev suggested could be okay as a tradeoff
between security and limiting behavior. By allowing a few tags and
attributes commonly used in "inline" messages, we "escape" while still
being a bit flexible.
The only drawback of that which I could see is if a developer uses these
functions for a message like "The <div class="test"></div> tag has some
problem.", in which case that HTML, which is a crucial part of the
message, would be stripped. That is possibly an edge-case though. If we go
with a `wp_kses()` based approach, we could still document that. In case
the error message ''intentionally'' contains HTML that is part of the
actual message, I would argue then it would be the developers
responsibility anyway to encode this, even or particularly when it's being
displayed somewhere.
I almost wish there was a function like `wp_kses()` but which doesn't
strip other disallowed HTML and instead escapes it. But that's probably
going too far. So I would be okay with the approach suggested by @costdev.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/57686#comment:50>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list