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:
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 there are 900 results for "Google Analytics" in the official repository, it's safe to say we've failed all but the advanced user.
— Erick Hitter (@ethitter) April 14, 2016
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.
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 https://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.
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.
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?
Development of my Authy for WordPress plugin continues with today’s release of version 0.3. There are two notable improvements contained in the latest revision.
First, administrators now have control over what role a user must have to enable two-factor authentication on his/her account. Subscribers don’t need Authy? Not a problem. Running out of API requests each month? Ensure that only those user roles with access to sensitive aspects of WordPress are protected by Authy.
Second, API keys can now be set in a site’s
wp-config.php file. Intended for WordPress Multisite users who network-activate the plugin, this enhancement eliminates the need to set API keys for every site on the network.
In addition to these changes, a number of improvements to the plugin’s interactions with the Authy service are included in this release.
The latest version of Authy for WordPress can be downloaded at http://wordpress.org/plugins/authy-for-wp/ or installed/updated via the WordPress dashboard.