Software Engineering in WordPress, PHP, and Backend Development

Category: Articles (Page 19 of 257)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

Using Ray in WordPress Development: Rendering Data and Data Structures

TL;DR: We’ll see what Ray looks like when rendering data, data structures, and other information in the context of a custom WordPress plugin. We’ll also see how to leverage some of its built in functionality for making data structures much more readable from how we’ve historically been able to do so.


📝 A Note About the Ray Plugin

When it comes to actually using the Ray application within the context of WordPress, I’d like to bring some clarity to the different ways in which it can be installed.

  1. Ray can be installed as a Composer dependency which is what we did in the previous article.
  2. Ray can be be installed a plugin via the WordPress Plugin Repository.
  3. Ray can be installed as a must-use plugin by cloning the repository from GitHub, placing it into your mu-plugins directory and then updating environmental variables as per the documentation.

All of these are viable options. I prefer to use the first option because I’m a fan of Composer and managing my dependencies that way so this guide will be following that approach.

If you opt to use any of the approaches, great! This series, however, will not offer guidance on those methods.


⚠️ If you’ve not already set up your environment, please read the previous post and make sure you have the free version of Ray installed.

Continue reading

Using Ray in WordPress Development: Introduction

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:

  1. Debugging WordPress with Ray, Part 1
  2. Debugging WordPress with Ray, Part 2
  3. Install Ray Per Project at an Application Level

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.

Continue reading

Writing Helper Functions in Procedural Programming in WordPress

TL;DR: Here’s how you can write domain-specific, testable helper functions in procedural programming in WordPress.


If you decide to use procedural code when writing plugins or extensions for WordPress, this doesn’t mean that everything has to be in a monolithic function. That is, it’s still possible – and a good idea – keep domain-specific work contained within its own function.

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.

Continue reading

Install Ray Per Project at an Application Level

TL;DR: Here’s an easy way to incorporate Ray into all of your WordPress projects without needing to add use at the top of your project files. Thanks to my friend Aubrey for sharing this.


You know about Ray, right? I’ve talked about it twice already:

  1. Debugging WordPress with Ray, Part 1
  2. Debugging WordPress with Ray, Part 2

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:

use WP_Post;
use WP_Term;
use Spatie\Ray;

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?

We don’t have to do so.

Continue reading

Don’t Forget Procedural Programming in WordPress

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,
  • and more.

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.

Continue reading
« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑