[wp-trac] [WordPress Trac] #59282: WordPress should register custom error and exception handlers

WordPress Trac noreply at wordpress.org
Mon Sep 4 20:06:18 UTC 2023


#59282: WordPress should register custom error and exception handlers
-----------------------------+-----------------------------
 Reporter:  bjorsch          |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Bootstrap/Load   |    Version:  trunk
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 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.

 [https://github.com/WordPress/WordPress-Coding-Standards/ 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.

 While #43712 is similar to this issue, the reasons and solution space are
 different. That ticket wants enhanced handling of errors for better user
 experience. This ticket is satisfied with the existing UX, it just wants
 error output fixed properly instead of trying to make every generated
 error be "safe" in order to avoid the potential bugs.

 See also https://github.com/WordPress/WordPress-Coding-
 Standards/issues/2374#issuecomment-1703370109 where @jrf suggested I file
 this ticket.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59282>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list