Category: Articles (Page 1 of 248)

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

Manipulate Incoming WordPress REST API Requests

May 5, 2023 / Tom

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.

How to Run Custom Functionality Once in Multiple Plugins

April 26, 2023 / Tom

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.

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.
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?

Bankruptcy on Block Editor Blocks (But It’s Not What You Think)

April 21, 2023 / Tom

In August 2022, I started a series on Learning to Build Block Editor Blocks and I continued it for several months. The last thing I wrote in the series was the following:

So as I continue with the series, we’re first going to look at what’s required to implement a custom block that includes:

a heading,

a paragraph,

and an input field to help guide the ultimate output.

We’ll continue to use the customization options we’ve outlined in this post and show how we can apply them to what the user provides and how to ignore them for what we, as the developer, provide.

After that, we’ll look at adding an input to the frontend of the site as well as incorporating a SlotFill.

And though I had intentions to follow through starting at the beginning of the new year, I obviously never followed through with the series. In all of the years that I’ve been writing, sharing code, and generally participating in all things PHP, WordPress, and development, I don’t think I’ve ever simply declared bankruptcy on an actual series or even just on the consistency of blogging in general.

But that’s what I’m doing in this post.

Using Custom Tables for ACF Data

April 6, 2023 / Tom

In my previous post, I showed you how to import programmatically defined ACF data. However, I also mentioned that there are some issues you may encounter when dealing with large datasets, such as those that use the Repeater field.

The Repeater field provides a neat solution for repeating content – think slides, team members, CTA tiles and alike.

This field type acts as a parent to a set of sub fields which can be repeated again and again. What makes this field type so special is its versatility. Any kind of field can be used within a Repeater, and there are no limits to the number of repeats either (👨‍💻 unless defined in the field settings).
Repeat, ACF Manual

The Repeater field allows you to create a set of fields that can be repeated an unlimited number of times. While this is great for flexibility, it also means that there is no limit to the number of rows or fields that can occur. As a result, you may run into the upper limit of what the database can store.

For those who are familiar with the implementation of the Repeater field, you know that each time a new entry is added to the post that the Repeater is attached to, a new set of records is added to the postmeta table. Over time, this can become a scalability issue.

That is, the post table will hold the post to which the repeater is attached. Then every time a new entry is added to said post, a set of new records will be added to the postmeta table.

Overtime, this won’t scale. More specifically, you’re going to hit a point as to where adding a new row in the repeater won’t work. And this is where the alternative solutions for custom data tables tables for ACF comes into play.

How To Import Programmatically Defined ACF Data

March 30, 2023 / Tom

For as nice and as powerful as ACF is, it’s not without it’s shortcomings (but I guess that could be said about any software). For the purposes of this post, though, this is the software about which I’m discussing.

Specifically, I’m talking about the following scenario:

You have a repeater field that’s defined programmatically and thus doesn’t show up in the WordPress administration area,
The data contained within the repeater field is so much that it exceeds the amount of data that can be efficiently stored in the postmeta table.

I was going to cover each of these in one post but given that they aren’t really related, it seems to make most sense to separate the content.

In this post, I’m going to cover how to import a programmatically defined ACF group. And in the next post, I’ll talk about solutions for migrating data into its own table.