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 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.
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?
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.
Should only those users with smartphones benefit from two-factor authentication? Authy didn’t think so, so they let users receive their tokens via a text message.
Tonight I’ve updated the Authy for WordPress plugin to support SMS-based tokens. Upgrade to version 0.2 to take advantage of this feature.
No additional plugin configuration is necessary, but Authy does ask that you have at least their free Starter plan to use this feature.
Authy for WordPress can be downloaded at http://wordpress.org/plugins/authy-for-wp/ or installed/updated via the WordPress dashboard.
I’ve been busy this week writing some new plugins.
First, I released Jetpack Photon for NextGEN Gallery, which extends the WordPress.com CDN capabilities in Jetpack to galleries built with the NextGEN Gallery plugin. I built this one after building Jetpack’s Photon module and noticing that NextGEN Gallery images weren’t benefitting from the Photon CDN.
Then, I enabled two-factor authentication on my CloudFlare account. CloudFlare uses a hosted service, Authy, rather than a local codebase, to handle the verification process using an installed app and a hosted API. Surprisingly, there wasn’t a WordPress plugin that integrated the service, but there is now: Authy for WordPress. It’s in use on this site, in fact.
Both plugins are available in the WordPress.org plugin repository. Development can be found at http://github.com/ethitter/Authy-for-WP and http://github.com/ethitter/jetpack-photon-for-nextgen, respectively.