Author: Tom (Page 24 of 426)

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.

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.