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.
It recently came to my attention that the content of password-protected posts could be disclosed via the print templates added by WP Print Friendly. Version 0.6 corrects this deficiency.
Additionally, for privately-published posts, the plugin will no longer display a print template if the current viewer can’t read the content. Instead, the not found (404) template in the active, non-print theme will be displayed.
I also took the opportunity to convert the plugin to a proper singleton1, improve the internal documentation, and ensure that all aspects of the plugin are ready for translation.
I owe a thanks to Steven Word, a new contributor to the plugin, for adding a hotfix for the content disclosure problem until I had a chance to correct the underlying issues. Upgrading to version 0.6 is strongly recommended.
VAPP, as I abbreviate it out of laziness, shares a small amount of code with WP Print Friendly. Thankfully, given the nature of the plugin, it wasn’t similarly vulnerable to content disclosure in the way WP Print Friendly was. In the process of confirming it wasn’t vulnerable, I made a few improvements.
Like I did with WP Print Friendly, I converted the plugin to follow a proper singleton pattern, enhanced the inline documentation, and updated a few strings that weren’t translation-ready.
This is one of my more-obscure plugins, one that’s meant for developers to leverage in their plugins and themes. It hadn’t gotten a lot of attention since I released it in June 2012, and the code reflected that.
Version 0.3 corrects a situation that resulted in PHP warnings because I’d improperly used the WordPress database class’s method for ensuring queries are safe (
$wpdb->prepare()) where it wasn’t needed.
As I did with the two preceding plugins, I also updated the code to follow the singleton pattern and corrected much of its internal documentation.
I’ve recently begun maintaining the WP-Cron Control plugin, both because it was created by a former colleague at Automattic, and because I use it on this and several other sites on my network.
I’d noticed that
$wpdb->prepare() was incorrectly used in this plugin much like I’d done in Date-based Taxonomy Archives, resulting in a pile of PHP warnings in my server’s error logs. Version 0.7 remedies this situation.
I also continued my quest to make everything translation-ready by ensuring all strings in the plugin options screen are properly tagged.
The remainder of the plugins I created or contribute to were tested and their WordPress version compatibility updated to reflect that they work with 3.6. These are:
- Authy for WordPress (WP.org | GitHub)
- Automatically Paginate Posts (WP.org | GitHub)
- External Permalinks Redux (WP.org | GitHub)
- Jetpack Photon for NextGEN Gallery (WP.org | GitHub)
- Taxonomy Dropdown Widget (WP.org | GitHub)
- Taxonomy List Widget (WP.org | GitHub)
An astute observer will notice that some of my plugins still don’t follow a proper singleton pattern, instead relying on a global variable as I was fond of doing at one point. I have every intention of converting the balance of my plugins to singletons, which will likely happen as other updates to them are needed. At that time, I’ll also ensure the internal documentation is up to par and that the plugin is able to be translated.
If anyone’s up for translating any of my plugins, get in touch!