You notice something’s wrong and use available tools to help you find out what’s going wrong.For highly interactive debugging you can use a PHP debugger. But there are times when you can’t, or don’t want to, use a PHP debugger. And there are situations where existing logging and tracing facilities don’t provide enough information in the area you’re investigating. So you need to obtain output that shows the values of things, with some contextual information to help you identify when and where the code was invoked. You often introduce new logic into your code that helps you report on the state of processing. Sometimes your new logic alters the results returned to the browser and can appear to make things worse before you’re able to make them better. That’s where the oik-bwtrace plugin fits in. Instead of coding a load of echo statements, print_r()s and/or var_dump()s, along with a smattering of debug_backtrace() calls I use two fairly advanced APIs; bw_trace2() and bw_backtrace(). The output they produce is written to trace files which I can browse in a separate window or tab. If I need more information I add some trace calls and run the output again. When satisfied with the results I can either remove the trace calls, comment them out or leave them in place with a trace level set to BW_TRACE_DEBUG. In this short video I explain the oik-bwtrace solution. I use it in my plugin development in preference to using a PHP debugger. You may also find it useful in your own development environment, or when performing problem determination. There are other tools available. Many of them only work on the front-end. oik-bwtrace can be used to trace every transaction: AJAX, CRON, XMLRPC, etcetera.
Additional notes
- Well defined trace points can assist formal problem determination
- Too much tracing can affect performance
- A well written trace routine should not affect the results obtained
- It’s a pity, but sometimes things can still go wrong when certain levels of tracing are activated.
