As nice as event-driven programming can be within the context of WordPress’ hook system, one of the challenges is preventing code from executing every single time the hook is called.
For example, say you’re writing a function that fires during the init action but something happens in WordPress core that triggers the init action to fire again consequently causing your code to fire once again even though it’s unneeded.
Multiply this across however many callbacks spread across however many files and general functionality registered with the hook and you may end up affecting performance and/or executing code that has no need to be run.
Static Variables in Plugin Bootstrap Files
How an LLM thinks this post would look as an image.
One way this can happen is in a plugin’s bootstrap. Case in point: Say your plugin is registered with the init action and then it sets up a registry which in turn instantiates a set of subscribers that register services. Repeating this every single time init is fired is unnecessary.
Here’s a way to manage this:
add_action( 'init', 'tm_acme_function', 100);
function tm_acme_function() {
static $initialized = false;
if ( $initialized ) {
return;
}
$initialized = true;
// ... set up the rest of the function.
}
If you know how static variables work, you’re may already be doing this, you’re able to follow the above code, or both. And if that’s the case, there’s nothing else to see here.
But if not, static variables can be useful in this scenario because static variables maintain state between calls whereas regular variables are reinitialized every time the function fires. This means a static variable retains its value across multiple calls to the function.
Static Variables and Plugins
So having an static $initialized flag works like this:
$initialized starts as false.
When the function runs for the first time, the $initialized variable is set to true.
On subsequent calls, the condition if ( $initialized ) prevents the rest of the function from executing, effectively short-circuiting it.
And because of that, this:
prevents redundant execution,
optimizes performance by avoiding running unnecessary code (especially as it relates to registering duplicate functionality, running multiple queries, or trashing data unintentionally).
If your plugin’s bootstrap registers a callback with a WordPress hook, considering using static variables to prevent code from being called unnecessarily more than once.
To say that 2024 has been a year would be an understatement. Though I’m talking about things that have happened offline, the same can be said for the WordPress economy at large, too.
On a regrettable level, the degree at which I’ve written has decreased more this year than likely any other year since I’ve been writing. Some of this can be attributed to stage of life, some can be attributed to work, and some of this can be attributed to the rise of AI in our industry.
AI taking a bite out of WordPress (or something like that).
Though the goals of this question are not mutually exclusive, I think getting an answer fast often outweighs the “I’m looking for an answer but it was neat to also read about someone else’s situation while searching for it.” And this is why ChatGPT has “wrecked” some of the content a bunch of us typically write.
But, as stated, it’s been over a year since this was written. And since I work in R&D in my current role, we’ve done – and continue to do – a lot of work with the various systems, applications, utilities, and so on.
Given that, I – like many of you – have recalibrated my perspective on how this changes the work we do.
ChatGPT Didn’t Wreck Our Type of Content
Improved Productivity
First, it’s undeniable that when used properly, AI assistants can vastly improve productivity. I run both Copilot and Cody in my editor as I’m consistently evaluating which one performs best for a given use case. At the time of this writing, I’m partial to Cody though I also know Copilot is going to support multiple LLMs in the coming months (or weeks?).
So, sure, AI assistants have changed the way the work in our day-to-day but, as the months have passed, I’m no longer convinced it’s “wrecked” our type of content so much as it’s “drastically altered” how we explain – for lack of a better word – our content.
One of which is more neutral than the other.
Large Context Windows but Lacking Context
Secondly, for as much as I typically work with ChatGPT, Gemini, and/or Claude (is there a clever acronym for all of these, yet?) on a daily basis, I find myself continuing to enjoy well-written content either in newsletters (see The WP Minute, The Repository, or Within WordPress) or blogs (see Brian Coords, what Mike is doing over with Ollie, and so on). Though I’m but one person, each of these properties or people continue to publish even though LLMs are available for any of us to use.
And that brings me to the final point: There are reasons AI hasn’t completely wrecked the type of content I – and others – have often published:
AI hallucinates. Recommendations provided within a given LLM are presented with an authoritative sense regardless of if the recommendations even use hooks, function names, or language features that don’t exist.
Lack of context. LLMs do not have the context as to how a given developer arrived at a solution and why one was chosen over another. Sure, you can ask for a variety of solutions and tradeoffs but there are times in which it’s still faster to read from someone who’s had the same experience, shared it, and provided contextual information as to how and why they arrived at a solution.
Aggressive Autocomplete. I’m a fan of using coding assistants within my IDE. As I said, the level of productivity and speed of solving problems has definitely increased, but that doesn’t mean its attempts to autocomplete a piece of functionality are always helpful. It still takes a critical eye to review what’s being proposed and determine whether or not it’s worth integrating.
There are likely more and your experience likely varies – but I suspect aren’t much different – from mine.
The Why Behind the How
The reason I share all of this is because one of the fundamental things that is missed when working solely with AI is the value that human beings bring to the table when sharing the why behind the how.
This is not me taking a position on whether or not AI will, can, should, or whatever other argument is the current hot topic replace humans. Instead, it’s me saying that although I appreciate the value AI has brought to our industry and I recognize it alters the need for certain types of content, I no longer think it completely negates or replaces the type of content about I – and others – used to write.
Sure, our approach may need to be tweaked but there’s still plenty of ways to regularly share what we’re working on, how to solve a certain problem, and why one solution was chosen versus another.
Finishing 2024, Into 2025
Given that 2024 is coming to a close in the coming weeks and that we seem to have accepted the role AI plays in the day-to-day work of software development, perhaps I can start writing somewhat regularly once again.
There’s no shortage of things I’ve built, learned, saved, and archived. And while others have continued to publish their stuff, I’ve missed doing the same. Perhaps the coming weeks – and coming year – is a time in which those of us who so frequently wrote about development can find our way to back to doing exactly that.
TL;DR: If you’re using WordPress 6.1+ and aren’t able to schedule any type of job with Action Scheduler, this article explains the problem and a potential fix.
Specifically, this seeks to address the following message appearing in WordPress 6.1+:
Cron reschedule event error for hook: action_scheduler_run_queue, Error code: invalid_schedule, Error message: Event schedule does not exist., Data: {"schedule":"every_minute","args":["WP Cron"],"interval":60}
Resolve the Reschedule Event Error
Introducing More Logging
Starting in WordPress 6.1, additional logging was added to WordPress core. Specifically, the patch responsible for this includes the following description:
Rarely and randomly some of my custom cron events have disappeared. From searching around, I’m not the only one with this issue, and no one else was able to figure out why. I also was unable to debug the issue since wp-cron.php doesn’t log any errors nor have any hooks to try handling them. This patch adds those in.
Once this patch was introduced, it also resulted in others experiencing issues with cron and cron-related libraries starting from this ticket and then taking place in a specific forum post.
When you’re trying to create a schedule but it keeps blowing up.
And sure, these tickets are helpful as are the comments and the rest of the discussion in the forum. But there are times when we’re working on a specific task with a specific set of dependencies and need a specific solution.
Action Scheduler and Cron Jobs
My problem was this: I was trying to to register a job using Action Scheduler and the library wasn’t able to register the schedule because of the aforementioned problem.
So the fix was to add this function in my code:
/**
* Additional logging in WordPress 6.1+ that generates the following
* message regarding cron schedules:
*
* Cron reschedule event error for hook:
* action_scheduler_run_queue,
* Error code: invalid_schedule,
* Error message: Event schedule does not exist.,
* Data: {"schedule":"every_minute","args":["WP Cron"],"interval":60}
*
* This function needs to fire prior to loading Action Scheduler as its a
* pre-requisite for it to schedule our tasks.
*
* This filter seeks to manually add the schedule to the list of schedules to
* address this bug.
*/
add_filter('cron_schedules', function ($schedules) {
$schedules['every_minute'] = [
'interval' => 60,
'display' => 'Every Minute',
];
return $schedules;
});
A few things about this code:
I don’t recommend using this as a permanent fix for every case. It’s a specific solution for a generic warning.
If your codebase is going to be distributed to wide audience, avoid anonymous functions. If you have control over the environment in which it will return, it may be fine.
On the other hand, if you’re using Action Scheduler, WordPress 6.1+, and are trying to register your own jobs and are seeing this message, this will ensure schedules Action Scheduler uses are available.
When I first started writing about anonymous functions in WordPress back in January, I didn’t anticipate it spanning over three articles reaching into the fourth month of the year. But here we are.
That said, this final article in the series aims to help provide a short introduction to a number of technical ideas both in PHP and WordPress to explain why deregistering anonymous functions is nearly impossible.
And it provides a way for us to actually get contextual information about every single hook and callback in an instance of WordPress so we can handle the anonymous functions as we see fit all through the use of a plugin.
Recall from the first article, the reason I started writing about anonymous functions in WordPress all stemmed from a tweet (or post or whatever they are currently called) that stated:
I do wish developers would stop using WordPress hooks with (what I think are called) anonymous functions […].
They are very hard if not impossible to unhook.
And the short of it is that it’s true: Anonymous functions are easy to register against WordPress hooks and are difficult to deregister.
At this point in my career, I’ve been working remotely more than I have ever been in an office. I don’t ever want to have to return into an office unless it’s absolutely necessary.
Part of working like this, though, is maintaining a sense of self-discipline for the backlog of tasks required for work and doing so in such a way that makes it easy for me to focus on what I’m working on, what’s next, and what’s in the backlog. (If you’re a developer and you’re reading this, then you’re probably thinking kanban and you’re not wrong – but what I’m getting at is slightly different).
Before getting too much into the rest of the article, I do want to share that the majority of work I do right now is captured in Asana and organized by quarter. We have very little email and very little thrashing between emails, DMs, and other behavior commonly associated with the hyperactive hive mind.
[The] hyperactive hive mind as a workflow centered on ongoing conversation fueled by unstructured and unscheduled messages delivered through digital communication tools, like email and instant messenger.
But that doesn’t mean I don’t want to take a little further to not only help my day-to-day (especially during periods of increased business) but also to help give visibility to other people with whom I work so they know where a given task stands in my queue.
And don’t think this is me elevating my day-to-day any more important than yours. On the contrary. I’m sharing this to help give insight on what I’ve found that works so it may help you, too.
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.
