Как отключить ревизии в WordPress и ограничить автосохранение без потери удобства редактирования

Если сайт давно живёт на WordPress, ревизии постов и частое автосохранение обычно становятся тихой причиной разрастания таблицы wp_posts. Это не всегда критично на маленьком сайте, но на проектах с активной редактурой база быстро получает десятки тысяч лишних записей: старые черновики, автосохранения, промежуточные версии записей и страниц. В результате бэкапы тяжелее, запросы к админке медленнее, а чистка базы превращается в отдельную задачу.

Полностью отключать ревизии не всегда разумно. Для редакции они полезны, когда нужно откатить неудачную правку. На практике чаще нужен компромисс: оставить ограниченное число ревизий и уменьшить частоту автосохранения. Ниже — рабочие варианты, как это сделать без выдуманных плагинов и без поломки редактора.

Когда ревизии и автосохранение действительно мешают

Проблема обычно проявляется не сразу. Сайт продолжает работать, но админка начинает вести себя тяжелее, а база растёт быстрее, чем ожидается. Особенно это заметно на проектах с большим количеством авторов, длинными материалами и регулярными правками в Gutenberg.

Типичные симптомы

• в таблице wp_posts много записей с типом revision;
• в карточке записи в редакторе появляется слишком длинный список ревизий;
• бэкапы занимают заметно больше места без видимого роста контента;
• на слабом хостинге админка начинает подтормаживать при сохранении;
• после нескольких правок одна и та же запись создаёт десятки промежуточных версий.

Если сайт маленький и публикаций немного, отключать ревизии ради «чистоты» не нужно. Но если вы уже видите раздувание базы, ограничение ревизий — нормальная техническая мера.

Как понять масштаб проблемы

Перед изменениями стоит проверить, что именно разрастается. Не надо гадать по ощущениям: WordPress хранит ревизии как обычные записи, и это легко увидеть в базе.

Проверка через SQL

SELECT COUNT(*) AS revisions_count
FROM wp_posts
WHERE post_type = 'revision';

Если нужно посмотреть, какие записи занимают больше всего места по ревизиям, можно сгруппировать по родительской записи:

SELECT post_parent, COUNT(*) AS revisions_count
FROM wp_posts
WHERE post_type = 'revision'
GROUP BY post_parent
ORDER BY revisions_count DESC
LIMIT 20;

В phpMyAdmin или Adminer этого обычно достаточно, чтобы увидеть, есть ли смысл вмешиваться. Если ревизий немного, ограничение может быть избыточным. Если их тысячи или десятки тысяч, настройка уже оправдана.

Что лучше: отключить полностью или ограничить

Полное отключение ревизий подходит не всем. Для редакции и контентных проектов это часто слишком жёстко: одна неудачная правка, и откатить её уже нечем. Ограничение числа ревизий обычно безопаснее.

На большинстве сайтов разумный вариант — ограничить ревизии и уменьшить интервал автосохранения. Полное отключение имеет смысл только там, где контент почти не редактируют или есть отдельный процесс версионирования.

Пошаговое решение через wp-config.php

Самый надёжный способ — задать параметры на уровне wp-config.php. Это работает без зависимости от темы и не требует отдельного плагина.

1. Ограничьте количество ревизий

Добавьте в wp-config.php до строки /* That's all, stop editing! */:

define('WP_POST_REVISIONS', 5);

Это означает, что WordPress будет хранить только последние 5 ревизий для каждой записи. Если вам нужен более строгий режим, можно поставить 3. Если редакторы часто правят длинные тексты, 5–10 обычно достаточно.

2. Увеличьте интервал автосохранения

По умолчанию автосохранение срабатывает довольно часто. Для некоторых сайтов это нормально, но если редакторы жалуются на лишние промежуточные версии, интервал можно увеличить:

define('AUTOSAVE_INTERVAL', 120);

Здесь значение указано в секундах. В примере автосохранение будет происходить раз в 2 минуты. Это не отключает автосохранение полностью, а делает его менее агрессивным.

3. Не путайте ревизии и автосохранение

Это разные механизмы. Автосохранение защищает от потери текста во время редактирования. Ревизии сохраняют версии уже после ручного сохранения. Если отключить только ревизии, автосохранение всё равно останется. Если уменьшить только автосохранение, ревизии продолжат копиться, просто чуть медленнее.

Альтернатива через код в плагине или mu-plugin

Если вы не хотите править wp-config.php, можно вынести настройку в отдельный mu-plugin. Это удобно на проектах, где конфигурацию нужно держать под контролем и не завязывать на тему.

<?php
/**
 * Plugin Name: Limit Revisions and Autosave
 */

defined('ABSPATH') || exit;

add_filter('wp_revisions_to_keep', function ($num, $post) {
    return 5;
}, 10, 2);

add_action('init', function () {
    if (!defined('AUTOSAVE_INTERVAL')) {
        define('AUTOSAVE_INTERVAL', 120);
    }
});

Но здесь есть важная оговорка: константы лучше задавать именно в wp-config.php, а не пытаться объявлять их поздно на init. Для AUTOSAVE_INTERVAL корректнее использовать wp-config.php. Поэтому для реального проекта я бы не рекомендовал этот вариант как основной. Он полезен скорее как иллюстрация, а не как лучший способ.

Как очистить уже накопившиеся ревизии

Ограничение числа ревизий не удалит старые записи автоматически. Если база уже раздута, нужно отдельно почистить накопленный мусор. Делать это стоит аккуратно и только после свежего бэкапа.

Удаление старых ревизий SQL-запросом

Перед выполнением запроса проверьте префикс таблиц. В примере используется стандартный wp_:

DELETE FROM wp_posts
WHERE post_type = 'revision';

Это удалит все ревизии целиком. Если вам нужно сохранить последние версии, лучше использовать специализированную очистку через WP-CLI или плагин, который умеет работать с ревизиями аккуратнее. Но если задача именно в том, чтобы полностью убрать накопленный мусор после принятия решения об ограничении, такой запрос рабочий.

После удаления ревизий имеет смысл проверить таблицу wp_postmeta. Обычно там не остаётся критичных хвостов именно от ревизий, но на больших проектах всё равно полезно прогнать проверку базы и оптимизацию таблиц штатными средствами хостинга или через phpMyAdmin.

Как проверить, что настройка сработала

Проверка должна быть не на глаз, а по факту. После изменений откройте любую запись, сохраните её несколько раз и посмотрите, сколько ревизий создаётся.

• в редакторе записи откройте блок ревизий и убедитесь, что старых версий стало меньше;
• выполните SQL-запрос на подсчёт ревизий и сравните результат до и после;
• проверьте, что автосохранение продолжает работать, если вы его не отключали полностью;
• посмотрите размер бэкапа базы после нескольких дней работы сайта;
• если используете кеширование на стороне хостинга, убедитесь, что изменения не зависят от кеша — ревизии хранятся в базе, а не в кеше.

Для быстрой проверки можно снова выполнить:

SELECT COUNT(*) AS revisions_count
FROM wp_posts
WHERE post_type = 'revision';

Если число перестало расти бесконтрольно, настройка работает. Если ревизии продолжают множиться, значит, правка не попала в нужный файл или её перебивает другой код.

Частые ошибки и как их исправить

Ошибка 1. Отключили ревизии, но база всё равно растёт

Так бывает, если в базе уже накоплены старые записи. Ограничение влияет только на новые ревизии. Старые нужно удалять отдельно.

Ошибка 2. Поставили слишком маленькое значение

Если оставить 1–2 ревизии, редакторы быстро теряют полезную историю правок. На длинных материалах это особенно неудобно. Для контентных сайтов лучше начинать с 5 и смотреть по практике.

Ошибка 3. Попытались задать AUTOSAVE_INTERVAL не там, где нужно

Константы должны объявляться до загрузки WordPress-логики, обычно в wp-config.php. Если пытаться менять их в позднем хуке, результат будет нестабильным или вообще не сработает.

Ошибка 4. Удалили ревизии без бэкапа

Это самая неприятная ошибка. Если после чистки выяснится, что в базе были нужные версии материалов, откатить удаление без резервной копии уже не получится. Перед массовым удалением делайте полный бэкап базы.

Ошибка 5. Смешали ревизии с черновиками

Черновики и ревизии — не одно и то же. Черновик может быть отдельной записью, а ревизии — это версии существующей записи. Чистить нужно осознанно, не по названию в интерфейсе.

Что ещё стоит учесть для безопасности и производительности

Если сайт большой, ревизии — это только один из источников мусора. После их ограничения полезно проверить и другие зоны: автосохранённые черновики, спам-комментарии, временные записи плагинов, устаревшие transient-данные. Но не стоит делать массовую чистку «на всякий случай» без понимания, что именно удаляется.

Для регулярной поддержки удобно держать отдельный регламент: резервная копия, проверка размера базы, чистка ревизий, проверка таблиц, затем уже обновления ядра и плагинов. Если нужен более широкий набор инструментов для чистки дублей и технической оптимизации, можно смотреть в сторону решений уровня Clearfy Pro, но только если они реально закрывают ваши задачи и не дублируют уже настроенные процессы.

Практический минимум для такого сценария простой: ограничить ревизии, увеличить интервал автосохранения до разумного значения, удалить накопленный мусор и после этого проверить, что редактор по-прежнему сохраняет контент без сюрпризов. На большинстве сайтов этого достаточно, чтобы база перестала раздуваться без потери удобства для авторов.