Over the years, I’ve usually written some type of end of the year post centered around Christmas that also talks about what’s happening and what happened:
For the first set, it’s fun to look back at how things have changed, and for the latter, it’s neat to look back to see what caught attention over the last year.
These posts are the closest I get to the ‘end of the year’ type of posts and I’d like to eventually get one done for 2024 even if I don’t complete it before the start of the year.
For today, though, it’s a short post to say Merry Christmas and Happy Holidays.
Merry Christmas 2024
Whether or not you’re celebrating Christmas, Hanukkah, Boxing Day, something else, or nothing at all, may the week (or weekend) be good to you.
As for my family and me, we’re celebrating Christmas and spending time with extended family over the next few days.
It’s my favorite time of year and, as cliché, as it may sound, I dig spending it with those who are near-and-dear. And I think everyone should be so lucky.
With that, here’s to the end of the year and the beginning of the next.
For years, I’ve kept track of various resources that I’ve found useful. Having them here makes it easy to refer to them in the future should the need arise (don’t you refer back to your old posts? /s).
It also makes it easy for others to find them if they’re searching for them either in traditionalways or via some of the new ways we have to search (that latter of which is why I find value in still sharing content).
Anyway, over the last two weeks, there have a been four things I’ve found that I hope to look more into in the future. And if not, at least they’re here for posterity.
WP API Privacy. The default WordPress installation from wordpress.org automatically transmits extraneous information via various HTTP calls that occur in the admin. Some of this data may be cause for concern from a privacy perspective. This plugin seeks to limit that information, attempting to further protect your privacy in the process (via Duane Storey).
WordPress Plugin Attestation. Add this action to your deployment workflow to generate a build provenance attestation of the plugin ZIP file on WordPress.org (via John Blackbourne). For what it’s worth, “attestation” is just the verification that the software comes from where it claims to originate.
RAVE for WordPress. RAVE for WordPress is an automated tool which compares the contents of published packages of WordPress with the canonical source code to verify they have not been tampered with (via John Blackbourne).
Git Updater Lite. “Since Git Updater already gathers and parses this data, Git Updater Lite only needs to query an update server run by the developer” (via Andy Fragen).
And if you stumble across this post and are interested in anything I’ve written in the past week, you can find that below:
If you’re using WordPress and you’re looking for an extremely quick way to add this functionality to your local installation, add the following code to an mu-plugin …
Earlier this year, I swapped my local development environment over to Herd (along with a couple of other changes such as DBngin which is worth covering in another post).
There’s a lot to like about it one of which is how easy it is to begin capturing outgoing emails from whatever application you’re using.
Herd Pro provides an SMTP mail server on your local machine that catches all outgoing emails instead of sending them to the world. It displays them in Herds own email client and provides rich debugging capabilities for all types of emails.
Emails From WordPress in Laravel Herd
If you’re using WordPress and you’re looking for an extremely quick way to add this functionality to your local installation, add the following code to an mu-plugin:
<?php
/**
* Initializes the PHPMailer instance before it is used to send an email.
*
* This action hook is used to configure the PHPMailer instance with the necessary
* SMTP settings, such as the host, authentication, port, username, and password.
*
* @param PHPMailer $phpmailer The PHPMailer instance being initialized.
*/
add_action('phpmailer_init', function ($phpmailer) {
$phpmailer->isSMTP();
$phpmailer->Host = '127.0.0.1';
$phpmailer->SMTPAuth = true;
$phpmailer->Port = 2525;
$phpmailer->Username = 'WordPress';
$phpmailer->Password = '';
});
For example, I have a file – herd-mail.php – located in mu-plugins. Once this is added, any outgoing email from WordPress will be immediately captured and funneled to Herd’s email inbox for review.
Notes
PHPMailer is part of WordPress core so there’s no need to install a third-party library).
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.
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.