Ревизии WordPress: настройка и очистка базы

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

Проблема решается не отключением всего подряд, а нормальной политикой хранения: понять разницу между revision и autosave, выбрать разумный лимит, оценить фактический объём базы, сделать backup и только потом удалять старую историю. Ниже — безопасная схема для рабочего WordPress.

Что такое ревизия WordPress

WordPress сохраняет предыдущие версии поддерживаемых типов записей как отдельные записи типа revision. Благодаря этому редактор может открыть сравнение версий и восстановить более ранний вариант.

Официальная функция wp_revisions_to_keep() определяет, сколько ревизий хранить для конкретной записи. Документация WordPress указывает, что по умолчанию число ревизий не ограничено, если конфигурация не задаёт другое значение.

Autosave и revision — не одно и то же

Автосохранение нужно для защиты текущей работы редактора. Оно периодически фиксирует промежуточное состояние, чтобы материал можно было восстановить после сбоя вкладки, браузера или соединения.

Ревизия — это элемент истории версий. Autosave — механизм страховки текущего редактирования. Оба используют инфраструктуру revisions, но управлять ими нужно с учётом разных задач. Попытка «убрать ревизии ради скорости» может ухудшить редакторский процесс, не дав заметного выигрыша на фронтенде.

Почему база может разрастаться

Представим сайт с 5 000 статьями. Если каждая запись пережила десятки или сотни сохранений, количество строк типа revision может значительно превысить число опубликованных материалов. Дополнительно с частью версий могут быть связаны записи в wp_postmeta.

Это не означает, что ревизии всегда являются проблемой. На небольшом сайте лишние десятки мегабайт могут вообще не влиять на работу. Оптимизация оправдана, когда измерения показывают реальный объём и есть понятная причина уменьшать историю.

Как быстро оценить количество ревизий

Перед удалением полезно сначала просто посчитать данные. Например, через WP-CLI можно получить число записей типа revision без прямого изменения базы:

wp post list --post_type=revision --format=count

Если используется нестандартный префикс таблиц или большой managed-hosting, WP-CLI обычно безопаснее случайных SQL-команд из старых статей: он работает через контекст WordPress и не требует угадывать имя таблицы.

Также стоит сравнить размер wp_posts и wp_postmeta до и после обслуживания. Тогда эффект можно измерить, а не оценивать по ощущениям.

WP_POST_REVISIONS: основной лимит истории

Константа WP_POST_REVISIONS задаётся в wp-config.php. В официальной документации по wp-config.php описаны варианты: true, false или целое число.

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

define( 'WP_POST_REVISIONS', 10 );

Так WordPress сохраняет полезный запас предыдущих версий, но история не растёт бесконечно. Конкретный лимит зависит от редакционного процесса: для лендинга может хватить 5–10 версий, а для активно редактируемой документации — больше.

Почему я редко советую WP_POST_REVISIONS=false

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

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

AUTOSAVE_INTERVAL: как настроить частоту автосохранения

В wp-config.php можно изменить интервал autosave в секундах. Например:

define( 'AUTOSAVE_INTERVAL', 120 );

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

Если админка тормозит, сначала стоит выяснить источник нагрузки. Частые запросы могут быть связаны не только с autosave, но и с Heartbeat API, тяжёлыми метабоксами, плагинами или медленной базой. Отдельно я разбирал это в статье про Heartbeat API и admin-ajax.

Лимит не удаляет старые ревизии мгновенно

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

Если сайт годами работал без ограничения, старые записи нужно обслужить отдельно. Именно здесь чаще всего совершают опасную ошибку — запускают случайный SQL DELETE без backup и без понимания связанных данных.

Безопасный порядок очистки

Сделать полный backup. Нужны база и файлы, а не только экспорт WordPress.
Проверить восстановление. Backup ценен только если его можно развернуть.
По возможности использовать staging. Сначала повторить процедуру на копии.
Посчитать ревизии до удаления. Зафиксировать объём.
Удалять через поддерживаемый инструмент. WP-CLI или проверенный код предпочтительнее SQL из неизвестного источника.
Проверить orphaned metadata. После массовых операций убедиться, что не осталось мусорных связей.
Оптимизировать таблицы только при необходимости. Само удаление строк не всегда сразу уменьшает физический размер файла таблицы.
Проверить редактор и фронтенд. Создание, обновление, autosave и восстановление записи должны продолжать работать.

WP-CLI для удаления ревизий

На staging можно сначала получить список ID:

wp post list --post_type=revision --format=ids

После backup и проверки списка старые revisions можно удалить средствами WP-CLI, передав IDs в wp post delete. На больших базах лучше делать это пакетами, а не пытаться передать десятки тысяч идентификаторов одной командой.

Я намеренно не привожу «однострочный DELETE для всех таблиц»: структура проекта, объём данных, плагины и особенности базы могут отличаться. На production важнее контролируемая процедура, чем самая короткая команда.

Что происходит с postmeta

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

Удаление через API WordPress/WP-CLI предпочтительнее прямого SQL именно потому, что штатная логика лучше учитывает связанные сущности и hooks. Если используется кастомный post type или плагин со своей историей, сначала нужно проверить его документацию.

Фильтр wp_revisions_to_keep для гибких правил

Если один глобальный лимит не подходит, WordPress предоставляет фильтр wp_revisions_to_keep. С его помощью можно, например, хранить больше версий для важных страниц и меньше — для автоматически обновляемых записей.

Такой код лучше оформлять как небольшой mu-plugin или часть собственного плагина, а не вставлять в тему. Политика хранения данных относится к функциональности сайта и не должна исчезать после смены дизайна.

Пример: разные лимиты по типам записей

Логика может выглядеть так: страницы — 20 ревизий, записи блога — 10, технический импортируемый CPT — 3. Конкретные числа зависят от проекта.

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

Когда ревизии действительно влияют на производительность

Само наличие большого количества revisions не означает, что фронтенд обязательно станет медленным. WordPress не загружает все версии статьи при обычном просмотре страницы.

Проблемы чаще проявляются косвенно:

большая база дольше создаёт backup;
дампы медленнее передаются и восстанавливаются;
поиск и обслуживание таблиц становятся тяжелее;
админские запросы или неудачные плагины могут сканировать лишние строки;
миграции и staging-копии занимают больше времени и места.

Поэтому ревизии — часть общей оптимизации базы, а не универсальная причина плохого PageSpeed.

Не путать revisions с autoloaded options

Две проблемы часто обсуждают вместе, но это разные механизмы. Autoloaded options находятся в wp_options и могут загружаться на многих запросах. Ревизии находятся в структуре записей и относятся к истории контента.

Если сайт медленный, полезно диагностировать оба направления отдельно. Про wp_options и autoload я писал в материале «Autoloaded options в WordPress».

Какой лимит выбрать на практике

Универсального числа нет, но можно использовать рабочую отправную точку:

5–10 — небольшой сайт с редкими изменениями;
10–20 — корпоративный сайт или активный блог;
20+ — редакционные проекты, где история реально используется;
индивидуальная политика — крупные проекты с разными post types.

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

Чек-лист безопасной оптимизации ревизий

Измерить число revisions и размеры таблиц.
Понять, как редакторы используют историю.
Выбрать лимит вместо полного отключения без причины.
Настроить WP_POST_REVISIONS.
Менять AUTOSAVE_INTERVAL только после оценки редакторского риска.
Сделать backup и staging перед массовой очисткой.
Удалять историю контролируемыми пакетами.
Проверить связанные metadata и таблицы.
Протестировать создание, редактирование, autosave и восстановление.
Сравнить размер базы и время backup до/после.

Когда нужен отдельный аудит базы

Если wp_posts содержит сотни тысяч или миллионы строк, одной настройкой revisions лучше не ограничиваться. На таких сайтах одновременно могут копиться transients, Action Scheduler logs, orphaned metadata, WooCommerce sessions и данные удалённых плагинов.

В этом случае полезнее сделать карту таблиц и определить вклад каждого источника в размер базы. A.S Groups может провести такой аудит, подготовить staging, сделать безопасную очистку и настроить дальнейшее обслуживание WordPress. Для оценки можно прислать размер базы и описание сайта.