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.
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
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.
There are too many Google Analytics plugins in the WordPress.org repository. By my count, there are 900:
When one of these plugins recently changed ownership and rebranded in a poorly-promoted way, I began looking for a new solution. Frustrated by both the volume of related plugins in the official repository, and their unending lists of features that I didn’t need, I did what many perturbed developers would: I wrote a custom solution.
Continue reading Google Analytics overload
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
Many years ago, I used the HeadSpace2 plugin to manage SEO on a now-dormant site. I’ve left the plugin installed there to retain the data it holds, but recently decided to explore alternatives.
Continue reading Introducing a way to retain HeadSpace2 data without the original plugin
Today I released my newest plugin, WP Revisons Control. Leveraging the updated Revisions experience in WordPress 3.6, my latest offering gives users control over how many revisions are stored for each post type. Prior to WordPress 3.6, the number of revisions saved could only be set universally, for all post types.
WP Revisions Control adds a simple interface to the Settings > Writing page of your WordPress Dashboard:
Why is this helpful? First, revisions are stored in the database, and if many are stored, can cause bloat. This bloat may lead to slower queries, which can have a noticeable performance impact. The preceding issues are really only concerns for sites with high traffic, and in situations where posts are edited many times, however.
Second, the value of these revisions depends on what is being tracked, and one’s desire to retain the full revision history. For example, I may want to store every revision of the posts I write, but only desire to keep the latest five versions of each page on my site. Starting in WordPress 3.6, this control is available. Since this is a power-user feature, WordPress doesn’t provide a native interface to specify revisions quantities, so I wrote this quick plugin to do so.
My primary contribution to WordPress 3.6 was the changes that make this plugin possible. I’ve been looking for a way to demonstrate what’s possible with the updated Revisions functionality, and this plugin seemed like a fun and useful way to do so.
Download the plugin at http://wordpress.org/plugins/wp-revisions-control/ and contributed to its development at https://github.com/ethitter/WP-Revisions-Control.
As part of checking that that the plugins I maintain are ready for WordPress 3.6, I took the opportunity to fix a number of bugs, patch a few content disclosure vulnerabilities, and refactor some things I wasn’t pleased with.
Below is a rundown of all that changed. It’s worth noting that all of the plugins I actively maintain are compatible with WordPress 3.6, which will be released in the coming weeks.
Continue reading Updating all the plugins!
I spent today checking all of the plugins I contribute to, ensuring that they are compatible with WordPress 3.6. Beta 3 was released last night, so we’re getting closer to a stable release.
If you’re a plugin author, have you done the same?