Plugin updates and translation lessons

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.

Lessons Learned

Error message shown when a plugin is not properly prepared for translation
  1. 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.
  2. If your plugin includes a block-editor component that contains translatable strings, a call to wp_set_script_translations() is required.
  3. 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.

Compiling nginx with GitLab CI

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

Automating plugin releases to WordPress.org using GitLab CI

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

Monitoring and culling stale GitLab Runner instances

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 godo library, I put together a Go program to periodically cull stale Droplets.

Continue reading Monitoring and culling stale GitLab Runner instances

GitLab on the move again

After a few successful months of testing Packet.net, I've once again moved git.ethitter.com. The decision was purely financial–my GitLab instance doesn't receive enough traffic to warrant Packet.net's pricing. As far as reliability and value were concerned, Packet.net was excellent. I would've appreciated built-in backups, but otherwise, I have no complaints about the service.

It will likely come as little surprise that git.ethitter.com is back on Linode. Compared to Digital Ocean, Linode is slightly more-generous with its resources, and GitLab wants all the resources it can get.

The migration itself was quite easy, with most of the time was spent preparing the server; GitLab's backup/restore process did most of the hard work. Now I just have to finish the ancillary setup, like monitoring.

Managing domain and certificate expiration with DomainMOD

With 40 domains–plus a half dozen certificates–to track, I added the DomainMOD tool to my repertoire. Its API integrations, in particular, made it an appealing choice, as I had little desire to manually enter so many details. After three months, I’m quite pleased with my decision.

Installation was as straightforward as a git checkout, creation of a MySQL table, and the addition of a server block to my nginx configuration. With DomainMOD successfully running, I configured it to use my mailserver, then got to importing my domains.

Continue reading Managing domain and certificate expiration with DomainMOD

Abandoning StartSSL

After Mozilla’s devastating report, and both Chrome and Firefox’s decision to stop trusting StartSSL certificates issued after October 28, I had no choice but to replace the certificates I’d obtained through StartSSL.

The process took a few months, mainly due to the associated costs. While most of my StartSSL certificates were replaced with ones issued by Let’s Encrypt, there were a few cases where LE wasn’t appropriate. This primarily impacted domains that have many, many subdomains, however there were also a few cases where Let’s Encrypt’s three-month duration would’ve been burdensome. Ultimately I had to purchase three wildcard certificates, plus three single-domain certificates. With those installed, I’m now free of StartSSL/Wosign. After sixty days, I can rotate the pinned keys, impeding any further use of my legacy StartSSL certificates.