An editing marathon shouldn't erase yesterday's history.

I’ve been working with WordPress for over 15 years, and I’ve written plenty of plugins along the way. But Time-based Revision Cleanup is the only one I’ve felt was worth releasing publicly.

With WordPress 6.8 out, I recently updated the plugin and figured it was a good opportunity to explain why I built it in the first place.

The short version: WordPress revisions are count-based, when they really should be time-based.

The problem with counting revisions

WordPress’s revision system is useful. It gives editors a history of changes and a way to restore an earlier version of a post. But the standard retention choices leave something to be desired.

You can limit revisions in wp-config.php:

define( 'WP_POST_REVISIONS', 15 );

That tells WordPress to keep a maximum of 15 regular revisions per post. It’s a sensible-looking limit until you have a particularly busy editing session.

I’ve made 50 revisions in an hour. Between writing, rewriting, fixing formatting, and making small adjustments, it isn’t difficult to burn through 15 saves. Suddenly, the version you wanted to compare against from last week is gone.

The alternative is to allow unlimited revisions. That protects the history, but nothing ages out automatically. On a busy site, the database can grow to a ridiculous size over time.

Neither approach really matches how I use revision history.

History is about time, not the number of saves

When I open a post’s revision history, I’m usually trying to answer a question like:

• What did this page look like yesterday?
• What changed since last week?
• Can I get back to the version we published last month?

I’m not particularly interested in whether that version was 12 or 40 saves ago.

A busy afternoon of editing shouldn’t erase the context of what a page looked like before the work started. And a page nobody has touched in months doesn’t need to keep an unlimited collection of ancient revisions.

Retention by age makes more sense than retention by count.

What the plugin does

Time-based Revision Cleanup lets you manage revisions using a retention period rather than relying solely on a fixed number of revisions. You can choose a time window, such as 30, 60, or 365 days, and let the plugin clean up older revisions.

It is:

• Free and open source. No license fees or unnecessary dependencies.
• Time-based. The cleanup rules are based on revision age, not just how many times you’ve saved.
• CRON-capable. Cleanup can run on a schedule instead of during every post save.
• Configurable. You can adjust the retention period, cleanup schedule, and how much work a cleanup run performs.
• Lightweight. It’s intended to solve a specific problem without becoming a whole revision-management platform.

I especially like the option to disable save-based cleanup and let scheduled cleanup handle it. Revision maintenance doesn’t need to be part of the editing experience when it can happen in the background.

It made a real difference

I’ve been using the plugin for over a year on most of my client sites. On one very large client site, it reduced the database from 10 GB to 5 GB.

That’s not a benchmark I’m claiming everyone will see; the result depends on how much revision history a site has accumulated. But it illustrates why I wanted something better than either a hard count limit or unlimited retention.

It’s been a game-changer for me—as much as a better revision history can change the WordPress game, anyway.

If you maintain WordPress sites with active editors and a lot of revisions, take a look:

Time-based Revision Cleanup on WordPress.org