I can think of many excuses to explain why I’d, until recently, neglected my WordPress plugins. For some time now, I’ve only set aside time to bump their WordPress-version compatibility and respond to the occasional support thread. As my plugins’ users may have recently noticed, this has changed. I added block-editor (Gutenberg) support to both External Permalinks Redux and WP Revisions Control. I also fixed all of my actively-maintained plugins so that they can be translated through translate.wordpress.org. Today I’m revisiting a plugin, Automatically Paginate Posts, that I have ignored for more than two years; it requires some serious revisions to make it compatible with the block editor, and now feels like the right time to undertake that effort.
One interesting discovery that came from fixing my plugins’ support for translations was the realization that, while I thought I’d done everything correctly, I’d actually overlooked several key details. I was diligent about wrapping all user-facing strings in appropriate translation functions, and I’d followed best practices for building strings in ways that made them translatable as a whole (rather than concatenating translated chunks), but I hadn’t chosen proper text domains nor had I called all of the functions required to apply available translations.
- If your plugin supports WordPress versions older than 4.0, both the
Text Domain plugin header and a call to
load_plugin_textdomain() are required.
- If your plugin includes a block-editor component that contains translatable strings, a call to
wp_set_script_translations() is required.
- The plugin’s text domain must match its slug on WordPress.org if you wish to allow the community to submit translations that aren’t bundled with the plugin itself.
There’s a lengthy documentation page that covers all of the above and more: https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/. I should’ve paid closer attention to it.
Supporting My Plugins
If you find any of my plugins beneficial and would like to support my development efforts, please visit my donation page for links to various ways to provide financial support.
We moved recently into an apartment with a detached garage, and naturally, I wanted to incorporate that space into our home automation. To extend our network to the garage, I opted for powerline ethernet adapters, but soon discovered that the garage’s fluorescent light cuts the powerline connection.
To overcome this, I purchased an iHome iSP8 SmartPlug. It connects via wifi, which was a requirement since I don’t have a smart hub in the garage nor do I wish to add one there. It also includes a physical remote that I can mount near the now-disabled switch for the fluorescent lights. Continue reading Connecting an iHome SmartPlug to Home Assistant
Continuing my series on the fun I’m having with GitLab CI, it’s time to discuss using it to automate nginx builds. I’ve previously written about how and why I use a custom build, and a few months ago, I decided to remove the monotony from the process.
Now, when a new mainline release is available, or OpenSSL releases a new version, I update a few CI variables, run a pipeline, and a new nginx binary is available within a few minutes. I’m also able to build for multiple versions of Debian. Continue reading Compiling nginx with GitLab CI
Over the last few weeks, in anticipation of the release of WordPress 5.2 and to test my GitLab-CI-based plugin deployments, I’ve made minor updates to several of my plugins. Continue reading Recent Plugin Updates
I got started in WordPress development as many do, by writing a plugin. It, along with nearly a dozen others that I’ve released in intervening years, don’t require much attention, so I’ve generally neglected even the most-basic of maintenance: confirming each is compatible with the latest WordPress release and updating the readme accordingly. I’ve felt guilty about this for some time now, but it wasn’t until this weekend that that guilt compelled me to action. Continue reading Automating plugin releases to WordPress.org using GitLab CI
After I set up GitLab’s continuous integration using DigitalOcean Droplets for autoscaling, I noticed that sometimes, a runner would fail, abandoning a Droplet that I’d manually need to destroy. While this problem was infrequent, it was troublesome-enough to warrant some automated solution. Not finding anything readily available, and thanks to DigitalOcean’s Continue reading Monitoring and culling stale GitLab Runner instances
godo library, I put together a Go program to periodically cull stale Droplets.
I recently wondered how long it had been since I added ethitter.com to the Strict Transport Security preload list, as it’s been several years. I added my domain without fully understanding the consequences, though I’ve been fortunate to avoid any problems that could’ve resulted.
Getting back to my original question, version control made it easy to find August 18, 2014 as the date my domain landed in Chromium’s list: https://src.chromium.org/viewvc/chrome?view=revision&revision=290306. At the time, it was one of less than 1,000 domains in the preload list; the bulk of the list was comprised of Google’s own domains. There are currently over 40,000 preloaded domains in Chrome/Chromium. It’s a good thing preloading hasn’t been an issue, it takes a while to get off the list.
I took a break from my ongoing “convert everything to Ansible” project to use the base I’ve established there to install something new: GitLab Runner using Docker Machine. I finally have CI/CD built into my GitLab instance: https://git.ethitter.com/debian/eth-log-alerting/pipelines! 🎉 Continue reading docker-machine doesn’t require Docker locally
I’ve had entirely too much fun with Ansible this weekend. Looking forward to drastically improving how I manage my servers!
Two weeks ago, the VPS that hosts this site moved to a machine that had been patched for the Spectre vulnerabilities. Immediately, I began receiving warnings about high load, and these alerts continued unabated for over a week. I tried moving services to other hosts, and I reduced the resources allocated to
php-fpm, all to no avail.
As I continued to monitor and debug the situation, Continue reading Restoring performance after Spectre updates
fail2ban regularly appeared among the top resource consumers, but I didn’t think much of it;
fail2ban has always been a voracious resource user, but it’s an indispensable tool, so removing it wasn’t an option.