TL;DR: This is the first article in a series in which I’m going to walkthrough how to use Ray in WordPress development. From installation, plugin creation, and both beginner and advanced use of the application.
Starting last summer, I started to use Spatie Ray in my day-to-day work. I’ve written a few posts about it:
The more I’ve used the software and the more I’ve talked with other developers in the WordPress space, the more I see there’s potential for how to really leverage all the features the software offers beyond a glorified var_dump or print_r.
If you’re someone who’s comfortable writing code for WordPress but hasn’t gotten started with a debugger or is someone who is used to writing statements out to the browser, it’s my hope this series will provide you with everything you need to get started.
📝 Notes, Prerequisites, and More
I don’t necessarily have any pre-requisites as I’m going to be writing about Ray using an example plugin and project and doing so from the ground-up.
I do assume you have a local environment running and you’re comfortable working with Visual Studio Code or another IDE. When applicable, I’ll link to documentation that may be useful for setting up a development environment or diving deeper into a topic.
Though I plan to provide some explanation as to what we’ll be doing in a given step, such as installing Ray via Composer, I won’t necessarily be taking the time to show how to install Composer. Instead, I’ll link to other blog posts or available documentation to do that.
With that said, let’s get started with using Ray in WordPress Development.
So even if you’re using a weird mix of namespaces and autoloading along with procedural programming, you can still take advantage of functions that do one thing and one thing well to help keep the code a bit cleaner. I will say, though, this is where docblocks come in handy.
In this article, I’ll share an example of how to simultaneously using procedural programming, anonymous functions, and utility functions (or helper functions) to make sure that you’re writing code that’s well-documented and easy to follow.
If you’ve been using Ray in your WordPress projects and have been including it in your composer.json file, then you’ve likely set up the top of your files like this:
defined('WPINC') || die;
require_once __DIR__ . '/vendor/autoload.php';
Notice that the namespace for Ray is included in this. But if this is a utility meant for printing out error messages for debugging purposes, much like we’re used to seeing with Xdebug, then why would we include it in every file? That is, why would we include a use statement for a dependency that’s not sent to production?
TL;DR: As much as I like using object-oriented programming for writing code, it’s not the only way to write code. The same goes for WordPress-centric code, too. When writing solutions for WordPress, don’t set out to write everything in an object-oriented way. Don’t forget procedural programming in WordPress.
For the last few months, I’ve been writing a handful of small utility plugins (for lack of a better word) for WordPress. These are things that are designed to do at least one of the following:
add a feature that I wish exists but doesn’t,
improve functionality of the administration area to make achieving a given task easier,
introduce functionality that’s easier for a sites that have a large database of users,
As someone who’s historically been one to go on and on about why we should be using object-oriented programming, I’ve not been doing much of that in these plugins.
Instead, I’ve been using some features of PHP, like namespaces and autoloading, to keep the code running in its own area to prevent potential conflicts with other plugins. I’ve also been using PSR12 with procedural programming.
For as much as I’ve written about object-oriented programming, I don’t think I’ve written enough (and I certainly won’t do so in a single post 🙂) about procedural programming.
But that doesn’t mean now isn’t as good as time as any.
TL;DR: This is everything that needs to be done to install Xdebug with a Homebrew-based environment and to work with the software within Visual Studio Code.
Though I’ve recently become a fan of using Ray (1, 2) for much of my lightweight debugging, this doesn’t mean I don’t think it’s important to have Xdebug installed and configured in Visual Studio Code.
If you follow the steps I’ve outlined starting in the previous post, it’s relatively easy though it still requires a little bit of manual work to get started.
This is how you can set up Xdebug with a Homebrew-based configuration and Visual Studio Code.
If you are looking for WordPress guides and unbiased reviews, I recommend checking out WPKube. They also have an exclusive deals section.
Just Getting Started with WordPress? I write a lot about WordPress development but if you're just getting started, I recommend checking out WPBeginner. They have free training videos, glossary, and more.