As we continue looking at what it means to be an independent WordPress developer, the tools needed, and the various strategies that can improve our skillset, I’ve been talking through the various constants, plugins, and tools to help us.
If you’re just stumbling across this post, then I recommend checking out my guide to native WordPress debugging tools as well as the rest of the posts in the series thus far.
After all, I find it important that we’re all working off of the same foundation – or something closely related – when going through this information.
Ultimately, using a tool like Xdebug is indispensible, but we have to work up to that (for those who are curious, I wrote a brief guide about this a little over a year ago).
For now though, let’s start with the basics. In the previous post, I left with the following statement:
In the next post, we’ll start looking at what’s necessary to examine the error log that’s generated by WordPress and how to understand the information we see.
And that’s what I want to look at today because, if nothing else, it will give you something practical off of which to work.
Understanding WordPress Error Logs, Part 1
Before going too far into this, I do want to address one question that’s been raised from a member of the site.
Namely, I was asked:
When are we going to look at object-oriented principles?
Though I’ve covered a bit about this in a previous series, it’s something that I’m working to cover more in-depth later in this series.
With that said, though, let’s start looking at error logs.
Writing to the Error Log
In the next post, we’re going to take a moment to see how we can write to the error log. Sometimes, reading the file is fine and simply going back and forth between what we’re seeing and resolving the problems is nice.
But what about the case of when we want to dump something out to gain insight on what WordPress or PHP is seeing? That’s also useful.
So in the next part of this series on understanding WordPress error logs, we’ll do exactly that.
What’s After That?
Next, we’ll look at how to use some of the plugins previously outlined to test code and to also profile our code to make sure we’ve done everything we can to ensure we’re producing a level of quality.
This doesn’t mean that we’re completely done with the debugging process, but we’re definitely a step closer, and we’re positioned to write code with a degree of quality that doesn’t result in a file representing various nuanced problems we were too careless to fix (let alone understand).
