Reading and Understanding WordPress Error Logs, Part 2

Last time, we walked through the following:

1. configuring debug constants,
2. locating an error log file,
3. understanding how to read the log file,
4. understanding stack traces
5. understanding how to read the stack

As nice as that is, it’s still important to understand how to write data to error log from a programmatic aspect. That is to say; it’s one thing if your work throws errors, warnings, or notices.

It’s another thing if you want to understand how to write information to the file for research and debugging manually.

In this post, we’ll continue doing exactly that to further our understanding WordPress error logs.

[restrict paid=”true”]

Understanding WordPress Error Logs, Part 2

What’s the point of writing to the error log, anyway? I mean, is it even part of the debugging process?

From the previous post:

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.

When programmers think of debugging, many of them think of using an actual debugger (that is, a piece of software), setting breakpoints, and stepping through the code to watch the value of variables as the program executes.

We’re going to get to that point but before doing so, let’s take a look at how we can write to the error log ourselves to give us insight on how our work is performing.

After all, it’s one thing if our work is throwing warnings, errors, and notices. It’s another if there’s information that we want to see. And there’s where writing to the error log comes into play.

Understanding PHP Functions

To write to the error log, it’s important to understand two PHP functions:

1. error_log
2. print_r

As far as the error_log function is concerned, note that its purpose is to:

Send an error message to the defined error handling routines

In most cases, this is setup to write to the log file for us via the default WordPress and PHP configuration. But there’s more to it than that because we’re often going to want to output the values of variables, arrays, objects, and so on.

To that end, need to be able to use print_r in conjunction with error_log. print_r does the following:

Prints human-readable information about a variable

And if you read the manual, you’ll notice that it takes two arguments the second of which should be set to true if you want the result of a function to be printed to the log file.

Specifically, as the manual states:

If you would like to capture the output of print_r(), use the return parameter. When this parameter is set to TRUE, print_r() will return the information rather than print it.

So the general idea of writing our the value of an array, say $exampleArray, would look something like this:

But what about within the context of WordPress?

Writing Values to the Error Log in WordPress

So the above outlines the functions that are built into PHP that we need, but what does this look like in the context of WordPress development.

To do this, let’s say that we’ve implemented a version of the Registry Pattern. In our implementation of the pattern, we’ve also got a method called start that we can call once all of our objects have been added to the registry.

It may look something like this:

Now, as far as implementation is concerned, this is straightforward. But what if we want to see what objects are being invoked via each iteration of the loop.

The idea behind this is that we’re able to iterate through the stored objects and called a method on each of them. This is predicated on the idea that each of the objects has a method available on each of them (which can be enforced by an interface).

First, this raises a question: Why may we want to do that? Because of the nature of WordPress’ event management system, perhaps we want to make sure that each object we expect to fire does fire.

Secondly, how can we see what objects are being invoked? This is where writing to the error log comes into play. Using the methods that we’ve outlined above, one way to do that would be to do the following:

This will result in the following output:

Here, you’re able to see the object; it’s namespace, it’s property values (including whether or not the properties are private, protected, public, and so on).

From there, you can then do a bit of debugging if the output is what you didn’t expect or maybe you can use this to verify that your code is doing what you’d expect.

This is but one example, though. You could, however, dump the values of the $storage variable out before even iterating through the loop. That choice is really up to you and what you’re looking to achieve.

[/restrict]

Using the Installed Plugins

At this point, we’ve covered the foundational aspects of debugging code through the use of error logs.

Now though, we need to turn our attention to the plugins that were discussed a few posts ago. After that, we’ll eventually be working our way up to Xdebug.

But next, we’ll look at the tools available to us from within WordPress itself.