[wp-trac] [WordPress Trac] #28319: Add hook to WP_Error for logging and report purposes

[WordPress Trac]

#28319: Add hook to WP_Error for logging and report purposes
-----------------------------------+-----------------------------
 Reporter:  ebinnion               |       Owner:  johnbillion
     Type:  enhancement            |      Status:  reopened
 Priority:  normal                 |   Milestone:  Future Release
Component:  General                |     Version:  4.0
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |     Focuses:
-----------------------------------+-----------------------------

Comment (by carlalexander):

 I think that a solid set of hooks for errors is a necessary need for
 WordPress in the future. Your goals and ambitions with WordPress aren't
 slowing down. There's an API, more JavaScript client side, more ways for
 things to get handled silently by WordPress and hidden from developers (on
 top of overwriting PHP error logging settings).

 To have a great application platform, you need to have solid error
 handling. You need a way for developers to assess problems when they don't
 have access to debugging tools.

 > I think my bigger concern here is that WP_Error objects are not
 exceptions — rarely are they "exceptional."

 Right. You also have no exception to intercept either. This is an
 intentional design though. I understand that. The larger issue with
 WP_Errors is that there's no way to triage them. It's hard to filter
 relevant WP_Errors (they exist) from the noise. The WP_Error carries no
 weight, but it does when handled by the code in core.

 This means that not all WP_Errors are equal. I took a stab at trying to
 figure that out last year (http://carlalexander.ca/diving-into-wordpress-
 errors/). The main conclusion was that there was no easy way to track them
 down without checking every hook WordPress. You'd then need data after to
 see which one relevant or not.

 On top of that, WP_Errors are not always self contained. The most specific
 example is the http_api_debug hook. The WP_Error sent by the hook is not
 as useful without other variables passed in the hook. That means that any
 hook in the WP_Error object (on add or __construct) isn't very useful
 besides for tracking a message. You lack contextual information.

 > The REST API will make pretty liberal use of WP_Error (intentionally),
 and logging all of those alone would be problematic.

 I use WP_Errors a lot with the custom work I do with the API. It's great,
 but the API once rolled out will highlight this issue more. Anyone
 building an API based app will need to know what's going on their server.
 WordPress won't be able to handle errors in the same way anymore.

 > In addition, there's the possibility for a DoS attack using it if errors
 are logged to a DB.

 You could collect them during the whole execution and write everything out
 after the WordPress has terminated on the shutdown hook. There's
 definitely ways to minimize the impact otherwise people wouldn't use
 logging.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28319#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform