[wp-trac] [WordPress Trac] #33740: Create a new API to standardize application tracing

[WordPress Trac]

#33740: Create a new API to standardize application tracing
----------------------------+-----------------------------
 Reporter:  bobbingwide     |      Owner:
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Bootstrap/Load  |    Version:  trunk
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 Having read #30934 and #28319, I think it's best if I raise a new
 requirement.

 My proposal isn't about logging, it's related to problem determination
 tracing; the ability to dynamically activate trace logic to help someone
 to track down a problem.

 I have been using my own solution ( a plugin called oik-bwtrace ) for a
 while now.

 There are two dormant APIs that I need to make available at all times,
 even when tracing is not activated.

 Since these functions are currently not available by default I've had to
 be careful where I use them. To circumvent the problem of trying to use an
 API which doesn't exist, many of my plugins have dependencies on a base
 plugin which supplies the dormant APIs.

 Life would be a lot simpler if WordPress came with a set of dormant
 functions which I can rely on to exist.

 This proposal is for two trace APIs. It could easily be extended to
 support logging.

 The dormant APIs have the same basic structure
 {{{
 function dormant_api( easy to use parameters ) {
   global $api_set_active;
   if ( $api_set_active ) {
     lazy_api( easy to use parameters );
   }
 }
 }}}

 In this example $api_set_active is just a boolean.
 It's set to true when the API logic is activated, false otherwise.

 To cater for different levels of tracing ( or logging ) we can either
 implement the test in the dormant API, or pass it to the lazy_api().

 This solution is different from 'pluggable'.
 The dormant APIs need to exist, from very early on.
 The lazy APIs are provided by implementing plugins and should be
 implemented as pluggable.


 The two APIs I really do need are currently called bw_trace2() and
 bw_backtrace().

 I've attached the latest version of my shared library file that defines
 these APIs and the constants they use.

 Assuming that these APIs will be required to trace WordPress core logic I
 feel that they need to have been defined early on in wp-settings.php


 I therefore propose a new file called dormant.php which can, if the
 developer so wishes, be included in wp-config.php but would otherwise be
 loaded in wp-settings.php before load.php.

 Note: It's the implementing plugin's responsibility to know when it's safe
 to do things.
 In my implementation of a hook for the 'all' action I've used multiple
 strategies which involve loading my APIs in wp-config.php before wp-
 settings.php, using a Must-Use plugin to be able to record most hooks, but
 requiring a custom db.php to be able to capture everything. I can't do it
 before db.php since add_action()'s not available until then.

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