TL;DR: This final article will demonstrate how to use Ray in WordPress as an example of classic debugging.
No, it’s not the same as something such as Xdebug, but it demonstrates what we can do such as changing variables on the fly and changing the course of execution.
An Example of Classic Debugging
In this series, I’ve covered a lot of information on getting up and running with Ray specifically in the context of WordPress development. If you’re just now reading this post, you can check out all of the posts using the following tag or through the links below:
- Rendering Data and Data Structures
- Callers and Stack Traces
- Debugging Functionality
- Measuring Performance
In this final post, I’m going to attempt to pull most of what we’ve covered together into a single example so you can see how to use Ray to its fullest extent using its basic suite of functionality.
Ultimately, the goal will be to show not only how to you can take advantage of useful visual tools (like separators, etc.), but also how you can get as close as possible to debugging without an actual debugger (through the use of
pause, and other similar functionality).
Finally, this article is going to be a bit different as it will have us rewriting a bit of the code so track each of the features we’re looking at using. As usual, all of the code will be tagged and linked at the end of the article.
From The Beginning
This article will assume you’ve already got Ray installed and updated via
composer.json which has been covered earlier in this series.
Further, it also assumes you have a development environment set up, configured, and running, and that you can view data in the Ray application using a previous version of the plugin we’ve been working on.
If not, please refer to the Introduction on how to get set up. Otherwise, run
$ composer update to make sure you have the most recent versions of all dependencies.
With that, we’ll get started.
When I mentioned that we’re going to be bringing much of the functionality together into a single article, I also meant that we’re going to rewriting much of the code.
This gives us fresh eyes and an easier way to log exactly what’s going on with the code. So the first thing we’re going to do is set up a new callback to the
plugins_loaded hook and render that information in Ray.
Further, we’re going to separate each new call with a separator so it’s more visually appealing on the eyes.
This first bit of functionality is easy: We just want to see what part of WordPress core invoked this function and then we want to separate the with a separator:
The output of the code should look something like this:
Notice, from where, we can determine this function is called more than once. What if we want to make sure that didn’t happen except once? Then we could incorporate one of several mechanisms in place that would make sure it’s run only once.
For the purposes of this example – and this example only – I’m going to write a value into the options table. I’m not a fan of throwing any data into the options table and this is purely for demonstration purposes.
At the start of the function, add the following block:
At the end of the function add the following statement:
The final code should look like this:
Remember, this will need to be deleted before we’re done with the plugin. We’ll come back to this later. Now, however, the final output should look like this:
Nothing more than a single line showing what called this function. At this point, we can move forward with looking at some of the other features.
📝 Note: At any point during this article, if you’re unable to see output in Ray, then make sure you’re deleting the option from the table using
delete_option('ray-for-wordpress');. We’ll look at a strategy for this later in the article, too.
Another alternative would be not to place these parameters in place until the very end of the article. It’s your call, you have flexibility, but you can keep this in mind should you find Ray getting a bit confusing without much information is being printed.
Data Structures and Performance
Now let’s move into an area where we can revisit the simple data structure of an array.
Then we’ll do the following:
- randomly populate it to one size,
- measure the performance of iterating through it,
- then repeat the process while making the array grow larger.
First, we’ll write a utility function that will accept a range of numbers from which we can use to generate the numbers as well as the size of the array we expect:
Then we’ll call this within our main
plugins_loaded callback function.
Your output may vary since the numbers being generated are random. Before moving forward, though, let’s start profiling how long it takes to generate these random numbers.
📝Note: If you’re running this callback multiple times, then your output is going to be run more than once. This is where ensuring it’s only run once can come in handy but that’s your call. I’m going to wait until the very end when I’m showing a complete example.
Before moving into profiling, I’m also going to take advantage of Ray’s ability to render data structures in a clearer way though its
table function. So take note of the following line of code:
And see the final result:
Now, though, let’s start profiling adding more and more information into these data structures.
There’s a lot of different ways we could do this:
- reading objects from the database such as
- running queries to retrieve rows and rows of data,
- or using what we already have going.
Since the concept is applicable to all of the above, we’re going to continue working with what we have. That is, we’re going to to do the following:
- Generate four arrays of random numbers,
- Each array will be sized at 100, 250, 500, 750, and 1000 in terms of elements,
- Each array will be generated with numbers from 0 to 500,
- We’ll profile how long it takes to generate each array,
- Then we’ll measure how long it takes to iterate through each array.
It sounds like a lot but we already have a lot of stuff done that we need to get done. So let’s get started.
First, note that since we’re basically going to be doing the same thing several times over (with 100, .., 1000 elements) it will make more sense to write a utility function to take out some of the repeated code for us.
So let’s do that first.
Notice we’re still using the same function we wrote earlier. Now, however, we have a second function that accepts an array of values and iterates through them making it much easier to measure performance in a single location.
Now we can pass in 100, 250, 500, 750, 1000, and 10,000 into this function and easily measure the performance to generate the size of these arrays. In the main callback function, we can simply call:
And then the output will look something similar to this:
Of course, your mileage will vary based on the numbers you’ve chosen, the speed over your processor, and so on. One final thing we can do to, though, is to iterate through the generated array.
Iterating Through The Array
To make the most of this particular segment and to show how we can modify things on the fly much how we can when using a standard debugger, we’ll be taking advantage of the
pause feature in Ray.
This will allow us to run some code, pause, modify the subsequent code, and run again. To set this up, we’ll write yet another function that will allow us to easily iterate through a specified array
For example, the basic function may look like this:
And the modification to the
measureNumbers function looks like this:
This will take the numbers that are generated and pass the result into the
iterateThroughArray function we’ve created which is where we’ll be working on pausing functionality, modifying data, and then continuing.
But first, let’s see what happens with the code that we have. Assuming all things are set up correctly, we shouldn’t see anything new in Ray and there should be no errors coming from WordPress.
Now, though, let’s add our first pause statement to see what the size of the array is. We don’t want to add it on each iteration through the array because we’d be hitting continue over and over again.
If you modify the function so that it pauses at the beginning, it will look like this:
And the output will resemble the following:
Notice in Ray, though, that we see options to Continue or to Stop Execution. What if we were to modify the array through which it was iterating once it got to, say, the 10th index, and then set
$i equal to the length of the array.
This should stop the loop, right? Let’s try it.
Note, however, that once you hit pause, you can literally change any code after that to contain something else, to branch into another area of code, or to print something new.
The action would go something like this:
- When you hit pause, hop back into the editor,
- Make a change (even something as simple as printing something into Ray),
- Then hit continue execution.
- You should see the output happen.
This is as close to live debugging as you can get (such as modifying variables in memory with Xdebug). So give it a try and see what you can make happen!
For example, I’ll print out the current user’s information:
And I’ll see something like this if I’m not logged into the system:
📝 Note: It’s important to make sure you only implement this in a single thread. That is, make sure that you have the option set so the code doesn’t execute over and over; otherwise, you’ll see weird results happening in the
⚡Remember that I mentioned earlier, it’s best to delete the option after a single thread of execution has run. Since
plugins_loaded runs early, we can delete the option at
shutdown and make sure we’ve cleaned up the database.
🔖 Remember The Tag
Recall I’m using the
develop branch of the repository for each article. After the article, I’ll merge the contents of
main and then I’ll tag the version with the date the article was publishing.
The tag for this article will be
This concludes my series on Ray in WordPress Development. I do hope you’ve found it useful and that this is something you’ll consider adding to your day-to-day work and it’s extremely easy to use, powerful, and makes debugging a bit
You can also find all of the gists used throughout this series on this page.
☕️ Enjoyed this guide? Consider Buying Me a Coffee to support more longer form articles!