Override PHP's default error and exception handler printing #5136
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dingo-d
reviewed
Sep 5, 2023
paulshryock
reviewed
Sep 5, 2023
WordPress relies on PHP's `display_errors` setting for error reporting. One unfortunate result of that is that errors containing HTML may be served to the browser unescaped. WordPress/WordPress-Coding-Standards tries to help avoid this by having a sniff (WordPress.Security.EscapeOutput) that, among other things, asks that strings passed to `trigger_error()` and `throw new SomeClass()` be escaped. This is not a very good solution for a few reasons: * It doesn't do anything about errors or exceptions thrown by PHP itself. * It doesn't do anything about errors or exceptions thrown by libraries that might be bundled into themes or plugins or any custom code blog authors might inject. * It means that text-based log files, non-HTML emails, CLI output, and the like will contain HTML entities. Instead we should follow the principle that values should be escaped close to the point of output, when we know what kind of escaping will be needed. Which, in the context of PHP, means using `set_error_handler()` and `set_exception_handler()` to handle the outputting. But WordPress also relies on various other things that PHP's default handlers do, not all of which we can duplicate. But on the plus side since `display_errors` is not exactly a boolean (and PHP doesn't care anyway) we can have the handlers themselves set `display_errors` to a sentinel value that PHP will interpret as "off", do any necessary output, and then hand off to PHP's default handlers to do everything else.
And also don't bother replacing falsey values with "wp".
…config. That also requires separating the "print" logic into a separate helper function.
anomiex
force-pushed
the
add/set_error_handler
branch
from
222db53
to
23ab66a
Compare
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
This seems opposite to how we do anonymous functions, but 🤷.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WordPress relies on PHP's
display_errorssetting for error reporting. One unfortunate result of that is that errors containing HTML may be served to the browser unescaped.WordPress/WordPress-Coding-Standards tries to help avoid this by having a sniff (WordPress.Security.EscapeOutput) that, among other things, asks that strings passed to
trigger_error()andthrow new SomeClass()be escaped. This is not a very good solution for a few reasons:Instead we should follow the principle that values should be escaped close to the point of output, when we know what kind of escaping will be needed. Which, in the context of PHP, means using
set_error_handler()andset_exception_handler()to handle the outputting.But WordPress also relies on various other things that PHP's default handlers do, not all of which we can duplicate. But on the plus side since
display_errorsis not exactly a boolean (and PHP doesn't care anyway) we can have the handlers themselves setdisplay_errorsto a sentinel value that PHP will interpret as "off", do any necessary output, and then hand off to PHP's default handlers to do everything else.Trac ticket: https://core.trac.wordpress.org/ticket/59282
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.