Software Engineering in WordPress, PHP, and Backend Development

Tag: WordPress (Page 6 of 219)

Articles, tips, and resources for WordPress-based development.

Yes, They’re Still Exciting: Headless WordPress Applications in 2023

In r/ProWordPress, OP asked a few questions around Headless WordPress in 2023. One question stood out the most:

Developers who develop headless WordPress sites, how are things going in 2023?

Given all that’s happened within the core WordPress application over the last few years – that is, with the Block Editor and Full Site Editing – it’s not only easy to lose sight this is functionality built into WordPress but there’s likely a portion of people onboarded into WordPress development who do almost nothing with this type of work.

Even with all of the excitement around the new editing tools and how much JavaScript has been introduced into WordPress core, building headless applications with WordPress is still something I find to be one of the most powerful aspects of working with the application.

Continue reading

How To Build Headless WordPress Applications with a REST API

Since both the REST API and Headless WordPress applications are now mainstream within the WordPress development economy, it’s likely developers have a standard set of tools they like to use when working on these types of projects.

Yours truly not excepted.

And though I’m not making the case that my set of tools should be the standard, I have a set of tools that I’ve found and consistently use when building headless WordPress applications with a REST API.

  • MailHog
  • Insomnia
  • JWT Auth

Though this isn’t in any particular order, I’ll outline them here, how I use them, and explain how they help with login and authentication, testing custom API endpoints, and reviewing emails sent from the local development environments.

Continue reading

Quick Tip: Verify Minimum PHP Version

Assume that your plugin requires a minimum version of PHP and you want to prevent activation if the minimum PHP version isn’t met.

Add the following code after you’ve declared your namespace, checked to make sure the plugin isn’t being directly accessed and so on:

if (version_compare(PHP_VERSION, '7.4', '<')) {
    exit(
        sprintf(
            'The plugin requires PHP 7.4 or higher. Your WordPress site is using PHP %s.',
            PHP_VERSION
        )
    );
}

If the comparison fails, then an error message will be displayed on the plugin activation screen along with the string you’ve passed to the sprintf function.

Manipulate Incoming WordPress REST API Requests

As I’ve continued to work with integration mobile applications with the WordPress REST API, there have been a few instances in which I’ve wanted to inspect, manage, or manipulate incoming REST API Requests.

There’s a number of reasons you may want to manipulate incoming WordPress REST API requests before they actually begin interacting with the core application. In my case, I needed to determine:

  • which endpoint is being requested,
  • check whether or not a specific key is being bassed,
  • return an error if not or proceed with further processing.

But that’s one of many different possibilities available. What I’m more interested in, at least in this article, is showing how to manipulate a request before it’s actually sent to be processed.

Continue reading

How to Run Custom Functionality Once in Multiple Plugins

Over the years, I think the concept of a “drop-in” plugin has become overloaded. What once referred to a very specific type of functionality has evolved to mean a couple of things.

  1. One of the definitions retains the original definition which is you can place specific files into the plugins directory to replace core WordPress functionality. These are not standard WordPress plugins, though. For example, you’ll likely often see files like advanced-cache.php or object-cache.php in the plugins directory. These are the original type of ‘drop-ins’ when it comes to working with WordPress.
  2. Another definition are plugins that aren’t specifically mu-plugins and they aren’t standalone plugins either. Instead, these are pieces of functionality that can be dropped into any other plugin and add functionality. Say you have two different plugins that are used by a lot of people and you want to give them the ability to add a feature without activating a new plugin. The way in which you can do this is have them drop a file into their existing plugin.

Here’s the challenge with the second definition: When you drop functionality of into the context of another plugin, that plugin may not be the only one already running the same code.

In other words, say you have a file called acme-functionality.php that can be added to any plugin. If you drop acme-functionality.php into multiple, activated plugins then you may end up with all kinds of results none of which are ideal. And why isn’t it ideal? Because you want the code to run only once.

What’s a way to check to see if a file is already running in the context of another plugin before running it’s code?

Continue reading
« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑