WP Revisions Control Released

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:

WP Revisions Control Interface

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.

5 thoughts on “WP Revisions Control Released”

  1. Hello Erick,
    I’m in the process to dissect your plugin and I dropped by to say thanks. And also hello.

    And I’ve a question. Wouldn’t be handy to have a button for simply trimming out (or erase) all the stored revisions on a particular page or post? Say that you aren’t going to change that content in future or you feel that keeping revisions on that particular entry isn’t relevant.

    Now back studying your way or coding in PHP which is quite different than mine and I feel I’ve something to learn from it 😉 Ciao!

    1. Thanks for the feedback! I’ve considered adding a post-level control, and will likely do so in a future release. The updates in WordPress 3.6 do provide enough data to allow a different number of revisions to be stored for each post, not just each post type.

  2. 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.

    It’s only “bloat” if you don’t need it, and I worry about the insinuation of automatically slower queries. This sort of things runs the risk of being repeated without any data to back it up, or specificity about when and where it matters. At what level does additional revision rows in the database cause noticeably slower queries? The way we use indices shouldn’t make a query against a 5mb table any slower than against a 1mb table. Is it dependent on the table size going above certain settings in the MySQL configuration? What’s the magnitude of the impact in terms of the overall page generation time?

    1. Fair points, Matt. I’ve updated the post to clarify my point in the excerpt you referenced.

      I have no data with which to provide quantified answers to your questions, but anecdotally, I expect that tens or hundreds of thousands of rows in the posts table, coupled with multiple thousands of visits, are likely necessary to trigger performance degradation that could be attributed to revisions.

      Hosting is also a factor here. For users on shared hosts, the quantity of revisions needed to slow queries down will be smaller than for users on dedicated servers.

      Ultimately, my intent was and is to provide users greater control over the revisions system without needing to code a custom solution.

Comments are closed.