A plugin turned off revisions for a whole WordPress site

A client's site lost the Revisions panel. Not on one post: on every post and every page, and the checkbox for it was gone from Screen Options too, so there was nothing left to switch back on.

Nothing had been deleted. 410 real revisions going back to April 2018 were sitting in the database the whole time, along with 472 autosaves, 16.2 MB in total.

The wrong theory that cost the most

WP_POST_REVISIONS set to 0 stops new revisions from being written. The obvious reading is that old posts keep their panel and only new edits go unrecorded. That reading is wrong, and it sent me down a dead end for several rounds.

wp-admin/includes/meta-boxes.php:1540 asks wp_get_latest_revision_id_and_total_count() for a count, and that function short-circuits at wp-includes/revision.php:709 before counting anything:

if ( ! wp_revisions_enabled( $post ) ) {
    return new WP_Error( 'revisions_not_enabled', ... );
}

wp_revisions_enabled() is false whenever the constant is 0. The caller checks ! is_wp_error( $revisions ) && $revisions['count'] > 1, so the metabox is never registered, and a metabox that is never registered has no Screen Options entry. The most-edited page on the site looks identical to a brand new one.

The REST API made it worse. /wp-json/wp/v2/pages/{id}/revisions was still registered and answered 401 rather than 404, because create_initial_rest_routes() gates on post_type_supports( $type, 'revisions' ), which the constant doesn't touch. A live revisions route proves post type support is intact and proves nothing at all about whether the editor will show the panel.

What it wasn't

Every one of these looks like the answer from inside wp-admin:

• Wordfence. No revisions feature at all. It only reports the constant, in wfDiagnostic.php.
• wp-config.php. No WP_POST_REVISIONS line in it. I read the file directly over SSH.
• Code Snippets. Zero hits for "revision" across the whole library.
• Avada and Fusion Builder. They do filter wp_revisions_to_keep, but post_revisions_limit was -1, which means "use the WordPress default", so the value passed straight through unchanged.
• Block versus classic editor. Swapping them changed nothing.
• LiteSpeed's database cleanup. It had deleted nothing. All 410 rows were still there.

GeoDirectory calls remove_meta_box( 'revisionsdiv' ) at class-geodir-admin-post-view.php:435. That one is real, and it is a red herring, because it's scoped to GeoDirectory's own post types.

The line that did it is wp-content/plugins/geodirectory/geodirectory.php:169:

$this->define( 'WP_POST_REVISIONS', 0 );

Site-wide, every post type, invisible from wp-admin. The last true revision on the site was written 2026-04-14.

The fix

One line in wp-config.php, above require_once ABSPATH."wp-settings.php":

define( 'WP_POST_REVISIONS', 10 );

GeoDirectory guards its own define with if ( ! defined( $name ) ) at geodirectory.php:455, so wp-config.php loads first and wins, and the change survives GeoDirectory updates. To undo it, delete the line and GeoDirectory's 0 takes over again on the next request. No data moves either way.

Pick a number rather than leaving it uncapped. 882 revision rows on this site cost 16.2 MB, roughly 19 KB each, because Avada stores whole shortcode layouts in post_content, and this is a host that already ran out of resources once this year. GeoDirectory sets 0 deliberately, for directory-scale data. If its post types carry real volume on your site, scope the change with a wp_revisions_to_keep filter that leaves gd_place and gd_classifieds at zero.

The 410 old revisions were reachable again the moment the constant changed, because nothing had been lost. The gap is what stays. Between 2026-04-14 and 2026-09-08 no revisions were written at all, so any page edited in that window has no earlier version to roll back to, and never will.