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.

Simple WordPress shortlinks

I recently decided to abandon YOURLS as my shortlink solution, opting instead to handle short URLs entirely within WordPress. This choice is not a reflection on YOURLS–it’s still a great product–but rather was borne from my use case for shortlinks; I concluded that, since I only used them in conjunction with WordPress, an external shortlink service was excessive.

While WordPress has provided a native shortlinks feature since the 3.0 release, it uses query strings rather than pretty permalinks. This means that the shortlink for this post would be http://ethitter.com/?p=6360. It’s not the prettiest URL, nor will many systems cache that request; as a result, each shortlink that’s followed would load all of WordPress just to perform a redirect to the post’s full URL. Unsatisfied with Core’s handling but also unwilling to retain YOURLS, I wrote a small WordPress plugin to address my needs.

Continue reading Simple WordPress shortlinks

Redis Object Cache for WordPress, the Accidental Effect of PHP 5.5

Last week, I went a little upgrade-crazy with the VPS that hosts this site. With SPDY 3.1 support in nginx 1.5, I upgraded. I also bumped PHP from 5.4 to 5.5.

The latter change is significant because PHP 5.5 drops support for APC, and I was using APC for both opcode caching at the PHP level and object caching at the WordPress level (thanks to Jaquith’s plugin). Since I’d lost my object cache, I’d also lost my page cache because I was using Batcache. Nice job, Erick.

Almost a year ago, I contributed two small changes to Eric Mann’s WordPress Redis Backend plugin. With Redis already running on my VPS for reasons unrelated to WordPress, it seemed an obvious choice over competing persistent caching options.

I spent some time updating Eric’s plugin (see https://github.com/ethitter/wordpress-redis-backend/commits/master for the fun I’ve had) and sent a massive pull request back with my changes. I’ve been using the plugin for a few days now without incident, though I wouldn’t rush to switch over just yet unless you’re adventurous. I’d watch Eric’s repo if you’re interested in what comes of my efforts.

Plugins Move to ethitter.com/plugins

To better showcase my web development work, I’ve relocated the pages related to my WordPress plugins to http://www.ethitter.com/plugins/. Any future announcements concerning plugin updates and new offerings will be hosted at ethitter.com.

As part of the move, my plugin development feed is now http://feeds.ldmh.us/ETHPluginDev. FeedBurner does not automatically redirect renamed feeds, so please update your reader accordingly. Anyone subscribed by email, however, should continue to receive updates.