TL;DR: There are a few PHP Code Sniffer extensions for Visual Studio Code. The one I prefer is PHP Sniffer & Beautifier by Samuel Hilson. Here’s where to get it and how to configure it.
Though this isn’t directly related to the material I’m writing about in my series on Ray on WordPress, it’s relevant enough to share at this point because:
the series is only going to include more code and i use this extension for writing said code,
over the last few months, I’ve found this extension to be really good in comparison to others that are available.
There are some other ones out that that are really good, and I’ve used them, but this is the one I’ve settled on using.
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.
Ray can be installed as a Composer dependency which is what we did in the previous article.
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.
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.
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:
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?
Kinsta offers premium managed WordPress hosting for everyone, small or large. Powered by Google Platform and strengthened by Cloudflare, they take performance to the next level. All hosting plans include 24/7/365 support from their team of WordPress engineers. Get startedwith a free migration today.
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.