Revision Strike

Unless post revisions are explicitly limited, WordPress will build up a hefty sum of revisions over time. While it's great to have revision history for some recent content, the chances that old revisions will be necessary diminish the longer a post has been published. Revision Strike is designed to automatically remove these unneeded revisions on older, published posts.

How does it work?

First, a threshold is set, with a default of 30 days. Once a day, Revision Strike will run and find any post revisions in the database attached to published posts with a post date of at least 30 (or your custom threshold) days ago, and "strike" (tear-down and remove) them from the WordPress database.

Usage

There are a number of ways to interact with Revision Strike:

WP Cron

Upon plugin activation, a hook is registered to trigger the revisionstrike_strike_old_revisions action daily, which kicks off the striking process. This hook is then automatically removed upon plugin deactivation.

The WP Cron method is great for ongoing maintenance, but when you manually need to purge larger amounts of revisions…

Tools › Revision Strike

You can manually trigger a revision strike by logging into WordPress and visiting the Tools › Revision Strike page.

Note: You must have the "edit_others_posts" capability (typically "Editor"-level and above) in order to see this page.

WP-CLI

If you make use of WP-CLI on your site you may trigger Revision Strike with the following commands:

$ wp revision-strike <command>

clean

Manually runs an instance of Revision Strike, removing revisions matching the passed arguments or defaulting to the values declared on the Settings › Writing page.

Arguments

--days=<days>

Remove revisions on posts published at least <days> day(s) ago. This is determined by the value set on Settings › Writing or a default of 30.

--limit=<limit>

The maximum number of revisions to remove. This is determined by the value set on Settings › Writing or a default value of 50.

--post_type=<post_type>

One or more post types (comma-separated) for which revisions should be struck. Default value is 'post'.

--verbose

Enable verbose logging of deleted revisions.

clean-all

If you have a large number of revisions, it can take Revision Strike some time to work its way through your post history to clean up revisions on a daily basis. The clean-all command is like spring cleaning, systematically removing eligible post revisions all at once, giving you a nice, clean revision history to start from, making it easy for the daily cron runner to maintain.

Under the hood, this command just determines how many eligible revisions are in the database, then calls the clean command with your arguments and a limit equal to the number of revisions in the database. Thanks to the revision chunking (#17), no more than 50 post revisions are being handled in memory at any given time, ensuring minimal performance impact on your site.

Arguments

--days=<days>

Remove revisions on posts published at least <days> day(s) ago. This is determined by the value set on Settings › Writing or a default of 30.

--post_type=<post_type>

One or more post types (comma-separated) for which revisions should be struck. Default value is 'post'.

--verbose

Enable verbose logging of deleted revisions.

Hooks

Revision Strike leverages the WordPress Plugin API to let you customize its behavior without editing the codebase directly.

Filter: revisionstrike_post_types

Controls the post types for which revisions should be automatically be purged.

(string) $post_types

A comma-separated list of post types.

Example

By default, Revision Strike only works against posts of the "Post" post type. If you'd like to include other post types (pages, custom post types, etc.), this filter will allow you do so.

/**
 * Include the "page" and "book" custom post type in Revision Strike.
 *
 * @param string $post_type A comma-separated list of post types.
 */
function theme_set_post_types( $post_types ) {
	return 'post,page,book';
}
add_filter( 'revisionstrike_post_types', 'theme_set_post_types' );

Filter: revisionstrike_get_revision_ids

Filter the list of eligible revision IDs.

(array) $revision_ids

Revision IDs to be struck.

(int) $days

The number of days since a post's publish date that must pass before we can purge the post revisions.

(int) $limit

The maximum number of revision IDs to retrieve.

(array) $post_type

The post types for which revisions should be located.

Filter: revisionstrike_capabilities

Sets capabilities to access Revision Strike managment page.

Example

By default, Revision Strike sets required capabilities to access plugin managment page as edit_others_posts. You can use this filter to change this in order to have more control on who can access it.

/**
 * Sets capabilities to access Revision Strike settings page.
 */
function rs_capabilities() {
	return 'manage_options';
}
add_filter( 'revisionstrike_capabilities', 'rs_capabilities' );

Contributing

All development dependencies for the plugin are installed via Composer. After installing Composer on your system, navigate your terminal session to the plugin directory and run:

$ composer install

Pull requests on this plugin are welcome, but I ask that you please follow these guidelines:

• Every PR that touches code should include a corresponding test. This plugin uses PHPUnit, WP_Mock, Mockery, and Behat. Every PR should generate a passing build in Travis CI before being considered for merger.

• Please follow the WordPress Coding Standards. If you have any doubts, you can run your PHP through PHP_CodeSniffer using the RevisionStrike ruleset:

    $ vendor/bin/phpcs
  

  This CodeSniffer ruleset combines the "WordPress-Extra" and "WordPress-Docs" rulesets for a very specific level of coverage; beyond the coding standards, contributed inline documentation will be checked against the WordPress Inline Documentation Standards.

Integration tests

There are a few integration tests for the plugin, written using Behat and scaffolded using wp scaffold package-tests. If you'd like to contribute to these tests, please install the WP CLI Testing framework:

$ bin/install-package-tests.sh
$ vendor/bin/behat