Stop letting every edit pile up forever in the database
Post Revisions caps how many revisions WordPress keeps per post, using the same approach dedicated performance plugins rely on — a page rewritten thirty times stays thirty-one rows in the database by default, and revisions are routinely the largest single category of rows on an established site.
- Set an exact maximum, disable revisions entirely, or leave the WordPress default.
- Defines the same WP_POST_REVISIONS constant dedicated performance plugins use.
- Falls back gracefully if the constant is already defined elsewhere.
- Recent revisions, the ones anyone actually restores, are always kept first.
Leave empty to keep the WordPress default (unlimited). Enter 0 to disable revisions completely, or a positive number to set the maximum.
What does Post Revisions do?
When the limit_post_revisions module is active and a value is set, TOWP_Performance defines the WP_POST_REVISIONS constant before WordPress's own internal setup would otherwise leave it undefined, matching how dedicated performance plugins like Perfmatters handle the same setting. A value of 0 disables revisions completely, a positive number keeps at most that many per post, and leaving the field empty makes no change at all, preserving WordPress's own unlimited default. Since the constant is already defined elsewhere, such as in wp-config.php, the module falls back to the wp_revisions_to_keep filter instead of trying to redefine it.
WordPress keeps every single revision, by default, forever
Because nothing prunes revision history on its own, an actively edited site accumulates rows without anyone deciding that was worth keeping.
Every save adds another row that never leaves
A page rewritten thirty times is thirty-one rows in the posts table by default, and none of them ever get cleaned up on their own.
Revisions are routinely the largest category of rows in the database
On an established site, the accumulated revision history often outnumbers the actual published posts and pages by a wide margin.
The recent history kept, the rest let go
The module caps how many revisions get kept per post, using the same reliable mechanism dedicated performance plugins rely on.
An exact cap, or none at all
Set a specific maximum, disable revisions entirely with 0, or leave the field empty to keep WordPress's own unlimited default.
The same approach performance plugins use
Defines the WP_POST_REVISIONS constant directly, the standard, reliable mechanism rather than relying on a filter alone.
Falls back cleanly if the constant is already set
If wp-config.php or another plugin already defines the constant, the module switches to a filter instead of causing a conflict.
The standard mechanism, handled carefully
Every capability below is present in the supplied PHP class and its settings registration.
WP_POST_REVISIONS, set early
The exact constant WordPress core itself checks, defined before its own internal setup would otherwise leave it unlimited by default.
The same approach, not a workaround
The module's own documentation explicitly notes this mirrors how plugins like Perfmatters handle the same setting.
Empty, zero, or a positive number
An empty field changes nothing, 0 disables revisions completely, and a positive number sets an exact maximum kept per post.
No conflict if something else got there first
Since a PHP constant can't be redefined, the module detects an existing WP_POST_REVISIONS and switches to the wp_revisions_to_keep filter instead.
The ones anyone actually restores
As new revisions get written past the limit, the oldest ones go, keeping exactly the recent history someone would realistically want to restore.
One setting among several performance tweaks
The revisions limit is gated by its own toggle, separate from Global Styles, Heartbeat, or Autosave Interval settings in the same performance group.
Where capping revisions helps most
The module supports any site where revision history has grown, or could grow, well past what anyone actually uses.
Sites with a long editing history on key pages
Cap revisions on pages that get rewritten often, like a homepage or key landing page, before their accumulated history becomes the largest table in the database.
General database housekeeping on an established site
Trim years of accumulated revisions as part of a broader effort to keep the database lean.
Sites planning ahead, before revisions pile up
Set a sensible cap from the start on a new site, so revision history never has the chance to grow unbounded in the first place.
A leaner database, the history that matters kept
The module combines a genuine reduction in row count with a sensible default for what stays available.
Set once, felt on every query afterward
The verified implementation is a one-time constant definition with a lasting effect on table size.
A constant, defined once, at startup
The change happens at initialization; there's no ongoing processing cost beyond WordPress's own normal revision-saving behavior.
Smaller tables, lighter backups
Fewer accumulated revision rows means a leaner database to query, back up, and migrate.
No effect when the field is left empty
With no value set, the module makes no change at all, and WordPress's own default behavior applies exactly as before.
A database setting, not an access boundary
The code manages retention, not who can view or restore what's kept.
A database and performance setting, not an access control
This module manages how much revision history gets stored; it has no effect on who can access, edit, or restore any given post.
No data loss for the revisions that matter most
Since the newest revisions are always kept first, the version history someone would realistically want to restore stays intact.
No conflict with an existing WP_POST_REVISIONS definition
The fallback to a filter means an existing definition elsewhere doesn't cause a fatal error or unpredictable behavior.
Configuration requires the same access as any other setting
Setting the revision limit happens through the standard TheOneWP settings screen, available only to an administrator.
Built directly around WordPress's own revision system
The supplied code integrates through APIs present in WordPress core; this page makes no compatibility claim beyond the verified implementation.
WP_POST_REVISIONS
The exact WordPress core constant that controls how many revisions get kept per post, defined directly rather than only filtered.
wp_revisions_to_keep
The native WordPress filter used as a fallback when the constant is already defined by wp-config.php or another plugin.
Part of the same performance toggle group
This setting is one of several independently gated performance tweaks, alongside Global Styles, Heartbeat, and Autosave Interval.
TheOneWP versus common alternatives
Compare the verified Post Revisions implementation with a typical filter-only approach.
| Capability | TheOneWP Post Revisions | Other common solutions |
|---|---|---|
| Mechanism used | Defines WP_POST_REVISIONS directly, the standard approach | Some plugins rely on the filter alone, which can behave less predictably |
| Conflict handling | Falls back to a filter if the constant is already defined | Redefining an existing constant can trigger a fatal PHP error |
| Value flexibility | Empty, zero, or any positive number, each with clear meaning | Some tools only offer a fixed set of preset limits |
| Which revisions get kept | The most recent ones, automatically | Consistent with how WordPress itself already orders revisions |
| Administration | One field, alongside other independently toggled performance settings | Often bundled awkwardly with unrelated database cleanup tools |
Cap revisions in four steps
Confirm the effect on a frequently edited post before considering it done.
Enable Post Revisions
Activate the module from the TheOneWP System settings tab.
Decide on a maximum
Choose a specific number, enter 0 to disable revisions entirely, or leave the field empty to keep WordPress's default.
Save the setting
Save the value; the new limit applies going forward as new revisions get written.
Confirm on a frequently edited post
Check a post's revision history after several more edits to confirm older entries are being trimmed as expected.
Match the cap to how the site actually gets edited
A limit that fits real editorial habits is more useful than a generic default.
Choose a limit based on actual editorial habits
A page that gets rewritten daily benefits from a different cap than one edited once and left alone.
Don't disable revisions on content still being actively drafted
Revision history is most useful while a piece of content is still evolving; a very low limit can remove exactly the version someone wanted to go back to.
Pair this with other database housekeeping for an established site
Since existing revisions aren't retroactively trimmed until a post is saved again, a broader database cleanup may still be worth considering.
Revisit the limit if editorial habits change
A site that starts publishing more frequently, or editing more heavily, may want to reconsider whatever cap was set initially.
Avoid mixing up empty, zero, and a real limit
A couple of details are easy to get backwards the first time.
Expecting existing revisions to disappear immediately
The limit applies as new revisions get written; it doesn't retroactively delete revisions already stored for a post that hasn't been edited again.
Setting the limit to 0 without meaning to disable revisions entirely
0 means no revisions get kept at all, not unlimited; leave the field empty instead to preserve the WordPress default.
Assuming this always works if another plugin defines the same constant
If WP_POST_REVISIONS is already defined elsewhere, the module falls back to a filter, so it's worth confirming the effective limit rather than assuming the field's value is what's actually in effect.
Post Revisions FAQ
These answers come directly from the verified class and its settings registration.
What does Post Revisions do?
It caps how many revisions WordPress keeps for each post, using the same WP_POST_REVISIONS constant dedicated performance plugins rely on.
What happens if I leave the field empty?
Nothing changes; WordPress's own default behavior, keeping unlimited revisions, applies exactly as before.
What does entering 0 do?
It disables revisions completely; no revision history gets stored going forward.
Does this delete revisions that already exist?
No. The limit applies as new revisions get written; existing revisions for a post that isn't edited again stay as they are.
Which revisions get kept when a limit is set?
The most recent ones; older revisions get trimmed automatically as new ones are written past the limit.
What happens if another plugin already defines WP_POST_REVISIONS?
The module falls back to the wp_revisions_to_keep filter instead of trying to redefine the constant, avoiding a conflict.
Is this the same approach dedicated performance plugins use?
Yes. The module explicitly mirrors how plugins like Perfmatters handle this same setting.
Does this affect who can restore a revision?
No. This module only controls how many revisions get stored; it doesn't change who can view or restore them.
Will this speed up my site?
It can reduce the size of the posts table, which every query against posts and pages has to work through, though the actual impact depends on how many revisions have accumulated.
Who can change the revision limit?
Only an administrator with access to the TheOneWP settings screen.
Stop letting every edit pile up forever.Cap revisions and keep the history that matters.
Use Post Revisions to set an exact maximum, disable revisions entirely, or leave WordPress's own default, using the same mechanism dedicated performance plugins rely on.