Category: WordPress

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.

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

Sorry VaultPress

PHP’s open_basedir is one way I isolate the various PHP applications running on my VPS. Within the directory that holds this WordPress install, there exists a symlink from when I relocated my presentation slides from http://ethitter.com/slides/ to https://slides.ethitter.com/. VaultPress doesn’t particularly appreciate this:

PHP Warning: file_exists(): open_basedir restriction in effect. File(/.../network/public_html/slides) is not within the allowed path(s).

Letting VaultPress access the directory that the symlink points to would defeat the purpose of using open_basedir, so instead, my VPS continually frustrates VaultPress.

What I Wish I’d Known When I Started–WordCamp Orange County 2016

This morning, I delivered an extended version of this talk, which I first presented at WordCamp Winnipeg 2015. This session explored WordPress functionality that new developers often overlook, as well as some “gotchas” about Core behavior. As a 90-minute workshop, extensive discussion was encouraged, and successful–so much so that I only made it about halfway through the slides. But, as I said at the outset, the slides were more a suggestion to guide the discussion.

Continue reading What I Wish I’d Known When I Started–WordCamp Orange County 2016

Why I use an editorial calendar

Someone asked recently why I use an editorial calendar for this site, with its low volume and single author. The reason is simple, and slightly amusing: to avoid publishing too frequently.

I’ve tried blogging challenges, and I’ve worked to post daily and maintain a streak as awarded through WordPress.com notifications.

I also found that the streak induced substantial stress to post daily, even when I had nothing worthwhile to share. Thanks to Edit Flow‘s calendar, I ensure that I post on no more than two consecutive days, as a defense against needing to publish daily.

Laugh if you want to, but this strategy’s enabled me to publish regularly since December 2015. Previously, one post per quarter was my about average.

Redirecting to your latest WordPress post

I had some time recently, and the idea struck me, so I put together a basic plugin that redirects /latest/ to my site’s latest post. Try it out:

Called ETH Redirect to Latest Post, the plugin is on WordPress.org now, as well as GitHub and my GitLab instance.

The plugin is ready for latest to be translated, but more importantly, it adds a field to your site’s Permalinks screen where you can set the slug.

Strangely, I couldn’t find a Core ticket for such a feature, and nothing turned up in the plugins repository, either.