I write a fair amount about coding standards with WordPress and the importance that I believe they have for individuals, teams, and with working with the core application, that being WordPress itself.
In the last year or so, I’ve moved away from working primarily with the WordPress Coding Standards and have begun to use PHP Standard Recommendations for coding.
Note that I did not say I abandoned the WordPress Coding Standards nor that I elevate the PSR recommendations above them, but I have reasons for when I use each. And for anyone working with WordPress-based projects, I think it’s important to recognize when it’s appropriate to use each.
And that’s the purposes of this post.
So far, this series has provided a series of screencasts that have provided:
In today’s screencast, I’m going to turn my attention to actually changing values at runtime while debugging. This means that while you’re executing your WordPress theme, plugin, or other web application, you can review and even change the values while the program is running.
This is useful not only for debugging but for testing various sections of code that allow us to trace how the code is performing, where it’s branching, and if it’s running exactly as we’d expect.
If you’ve been following along with the series thus far, then you’re likely seeing just how useful proper debugging can be especially when working on WordPress.
That is to say that not only are you able to gain valuable insights into your own projects, but you can see how WordPress core works, too.
At this point, though, we haven’t done much. As you may recall from the previous post (or if you haven’t watched the screencast, now is a good time to do so), you can see just how much debugging offers.
The truth is, we’ve barely scratched the surface. As I mentioned last time, this post and this screencast are going to focus specifically on the following:
In the next post, we’re going to look at more advanced things we can do such as stepping into functions, stepping out of functions, and stepping over functions.
We’re still not at a point where we’re going to worry about changing variable values on-the-fly, but we’re definitely going to see how we can strategically use the debugger to step into certain functions, step over certain functions, and step out of certain functions.
In the most recent post in this series, I walked through the process of integrating Xdebug with your IDE. And given that I’ve been using Visual Studio Code as my IDE of choice, that’s also the IDE I’m using as the example.
Furthermore, it’s cross-platform, easy enough to get started for beginners, but powerful enough to extend and operate for more experienced programmers (and for the rest of us who fall in between).
In the last post, I stated that I’d be doing a series of screencasts. Specifically, I wrote the following:
Starting in the next post, I’ll begin sharing some screencasts that walk through how to debug functions and variables, change values on the fly, work with the debug console, and more.
In this post, I’m going to have a short screencast providing an introduction to debugging WordPress the first part of this series. Namely, launching an instance of a site built using WordPress and using the basics of debugging a plugin.
Now that Xdebug is installed with your local installation of PHP, it’s time to wire it up to the IDE. This provides us with all of the advantages that Xdebug has to offer.
That is, it allows us to:
- set breakpoints,
- step through our code,
- and watch variables
All the while the program is executing. This means that while is a page is rendering, we’re able to set points in our codebase where we can see what the server is doing with our code.
So, sure, even though it’s called debugging to remove bugs, it can also give insight on how a WordPress-based application, theme, or plugin is executing and can help us gain a better understanding of WordPress core.