Debugging your WordPress site with action and filter tracing is now a lot easier, thanks to improvements in the oik-bwtrace plugin.
- Are you a WordPress plugin or theme developer?
- Would you like to know what’s going on behind the scenes?
- Do you want to find the best place to add your filter or action processing?
If your answer to any of these questions is Yes, then I suggest you read the rest of this article.
What problem determination methods are there?
Until I developed the action and filter trace functionality in oik-bwtrace (in April 2012), other than asking, I had four ways of finding out how WordPress worked.
- Read the code
- Read the codex or other documentation about WordPress
- Debug using a PHP debugger
- Trial and error with trace macros – using bw_trace2() and bw_backtrace()
and, of course, combinations of the above.
Action and filter tracing
In oik version 1.12, I added my first version of action and filter tracing. By adding some action and filter hooks I was able to trace the invocation of filters and actions that had already been registered. This was an improvement, BUT it was still hit and miss. My routines would only get called if there was already a hook registered. So I developed Immediate action tracing.
Immediate action tracing
In order to implement Immediate action tracing I needed to make modifications to a WordPress core file ( wp-includes/plugin.php ). Although the Immediate action tracing code was present in oik version 1.17, the modified version of plugin.php was not available to the general public.
In oik-bwtrace version 1.18.1219 I have now implemented a file switching routine that will replace wp-includes/plugin.php with the code that supports Immediate action tracing whenever it is enabled through the Dashboard. The file is switched back again when Immediate action tracing is disabled.
This automatic solution is available for WordPress 3.4.2, WordPress 3.5 and the latest development version 3.5.1-alpha.