My new BugNet for WordPress and the early Tracing feature

BugNet for WordPress is a library of debugging classes that work together. I’ve visioned my own debugging solution for 2-3 years but I held back because there are so many possible approaches and pitfalls. I’ve finally started my debugging solution (5% complete) and it already does something I can use in my latest plugin. So it has been released on GitHub for early use and I’ll begin adding it to the TwitchPress plugin later today.

BugNet Tracing for WordPress

My debugging solution is split into three primary services; Logging, Debugging and Tracing. I’ve been working on Tracing first because of my current client, Nookyyy (Twitch Streamer), requires it to finish a Twitch plugin we are working on.

Tracking offers the ability to build a series of log entries that are related. WordPress already offers a class for this called ‘WP_Error’ but it does not offer long-term storage or a way to continue a trace during multiple page requests. To make that happen with WP_Error() we would need to design it to happen so we start creating a debugging solution that extends what the WP core offers.

I’ve created an approach similar to WP_Error() but the difference is my use of transients. Trace entries are stored in a type of cache called transients. This allows us to continue a trace during multiple requests and with some more work, we’ll be able to create time delayed traces.

BugNet Tracing Data Dump

There is still a lot of work to do but what BugNet offers right now is already useful. Here is an example of the data gathered during a series of traces. BugNet allows a controlled trace ending i.e. we decide where we want the trace to be stopped and processed. If we do not choose a controlled ending, BugNet will process the trace automatically during the ‘shutdown’ phase.

Trace Data Explained (for Developers)

• Red Arrow: this is pointing to the boolean value that allows us to take control of when a trace is processed. This will grow into a more complex series of conditions so that we can trace during specific scenarios and end tracing using triggers.
• Green Arrow: this is a major part of BugNet and it is the reason BugNet is a large project, not just a debugging class but a library. The green arrow points towards output services that we wish to use for storing our trace. I’m putting a lot of work into how we read the finished data and present it to clients when solving problems for them.
• Blue Box: this holds the series of entries that make up our trace and you can imagine a far longer list that walks us through a PHP class or even an entire plugin. That is despite my example being setup in a single function but I’m just getting warmed up with my own tool.

What’s Next?

I will be integrating BugNet with TwitchPress today. The interesting part is that the objective is to do a trace within a TwitchPress extension. So there are a few integrations steps to take and that always presents new problems.

The problem I’m facing today is an issue that involves Twitch oAuth2. Visitors are not being re-directed to the correct place after using their Twitch account to login. The problem is that a re-direct might be happening and the user is being sent to the wrong place.

I need to setup a persistent trace that is maintained during multiple requests.