Если на сайте активно редактируют записи, ревизии быстро раздувают таблицу базы данных. Это не всегда критично на небольшом проекте, но на новостном сайте, блоге с длинной историей или ресурсе с несколькими авторами лишние версии постов со временем начинают мешать: база растёт, резервные копии становятся тяжелее, а очистка требует больше времени. При этом полностью отключать ревизии не всегда разумно — редактору нужна возможность откатить неудачное изменение.
В WordPress есть два рабочих подхода: отключить ревизии совсем или ограничить их количество. Выбор зависит от того, как вы работаете с контентом и насколько важна история правок.
Что именно делают ревизии и почему они разрастаются
Ревизия — это сохранённая версия записи, страницы или другого объекта, который поддерживает редактор WordPress. При каждом сохранении система может создавать новую копию содержимого. Это удобно, если нужно вернуться к предыдущему варианту текста, но неудобно, когда одна и та же запись редактируется десятки раз.
Проблема в том, что ревизии хранятся в базе данных как отдельные записи. Если сайт старый, а контент часто правят, их количество может исчисляться тысячами. Сам по себе WordPress от этого не ломается, но база становится менее аккуратной, а бэкапы — тяжелее. На хостингах с ограничениями по размеру базы это особенно заметно.
Когда ревизии лучше не отключать полностью
Полное отключение подходит не всем. Если на сайте есть редакторы, которые регулярно переписывают статьи, ревизии помогают быстро восстановить предыдущий текст после ошибки, неудачной правки или конфликта между авторами. Это особенно полезно, когда контент проходит несколько этапов согласования.
Отключать ревизии имеет смысл, если:
- сайт ведёт один человек и правки обычно точечные;
- контент публикуется редко, а история изменений не нужна;
- вы уже используете внешний контроль версий или отдельный рабочий процесс для контента;
- база данных заметно разрослась именно из-за старых ревизий.
Если же на сайте несколько авторов, безопаснее не отключать ревизии, а ограничить их число. Так вы сохраните запасной вариант на случай ошибки, но не дадите базе бесконечно расти.
Как отключить ревизии через wp-config.php
Самый прямой способ — добавить константу WP_POST_REVISIONS в файл wp-config.php. Этот файл находится в корне установки WordPress. Перед изменениями сделайте резервную копию: ошибка в wp-config.php может временно вывести сайт из строя.
Чтобы полностью отключить ревизии, добавьте строку перед комментарием /* That's all, stop editing! Happy publishing. */:
define( 'WP_POST_REVISIONS', false );После этого WordPress перестанет создавать новые ревизии для записей и страниц. Старые ревизии при этом не удаляются автоматически — они уже лежат в базе и останутся там, пока вы не очистите их отдельно.
Если хотите не отключать ревизии полностью, а ограничить их число, вместо false укажите целое значение. Например, так WordPress будет хранить только три последние ревизии:
define( 'WP_POST_REVISIONS', 3 );Это обычно более практичный вариант для живого сайта. Редактор сохраняет возможность отката, а база не раздувается бесконтрольно.
Как ограничить количество ревизий без потери удобства для редактора
Для большинства сайтов разумный лимит — от 3 до 5 ревизий на запись. Этого обычно хватает, чтобы вернуться к предыдущим версиям после неудачной правки, но не копить десятки одинаковых сохранений. Конкретное число зависит от того, как часто вы редактируете контент и сколько людей работает с одной записью.
Если статьи проходят длительное согласование и правок много, ставить слишком маленький лимит не стоит. Тогда редактор потеряет полезную историю изменений. Если же сайт обновляется редко, можно ограничиться двумя-тремя ревизиями без заметного дискомфорта.
Важно понимать: WP_POST_REVISIONS влияет на будущие ревизии. Уже созданные записи в базе останутся, пока вы их не удалите. Поэтому после изменения настройки обычно имеет смысл почистить старые ревизии вручную или через инструмент очистки базы.
Что делать со старыми ревизиями в базе данных
Если вы только ограничили или отключили ревизии, база сразу меньше не станет. Старые версии нужно удалить отдельно. Здесь есть два безопасных пути: через плагин для очистки базы или через SQL-запрос в phpMyAdmin, если вы уверены в своих действиях.
Для большинства владельцев сайтов проще и безопаснее использовать плагин, который умеет удалять ревизии и другие временные данные. Это снижает риск ошибки при работе с базой. Если вы работаете напрямую через phpMyAdmin, сначала сделайте полный бэкап базы данных.
Удалять ревизии вручную стоит только после проверки, что нужные записи не потеряют важную историю. На сайте с активной редактурой лучше сначала ограничить новые ревизии, а потом уже чистить старые поэтапно.
Как проверить, что настройка сработала
После изменения wp-config.php откройте любую запись в редакторе и сохраните её несколько раз. Если ревизии отключены полностью, новые версии создаваться не будут. Если установлен лимит, в блоке ревизий вы увидите только ограниченное число последних сохранений.
Проверить результат можно и в базе данных: в таблице wp_posts ревизии имеют тип записи revision. Если после нескольких новых сохранений их количество не растёт бесконечно, настройка работает. Учтите, что в разных редакторах и при разных сценариях автосохранения поведение может немного отличаться, но общий принцип остаётся тем же.
Что может пойти не так
Самая частая ошибка — редактировать wp-config.php не там, где нужно, или вставить строку в неправильное место. Константа должна быть определена до загрузки WordPress, иначе она не подействует. Ещё одна типичная проблема — ожидание, что старые ревизии исчезнут сами. Они не исчезают, пока вы не удалите их отдельно.
Если на сайте используется кэш или вы проверяете изменения не в админке, а через сторонние инструменты, не перепутайте отсутствие новых ревизий с проблемой редактора. Сначала проверьте сохранение записи в самой админке WordPress.
И ещё один практический момент: не отключайте ревизии на сайте, где контент регулярно правят несколько человек, если у вас нет другого способа отката. Экономия места в базе не стоит потери удобного механизма восстановления текста.
Если нужен компромисс между чистой базой и безопасной работой редактора, ограничение ревизий почти всегда лучше полного отключения. Для большинства сайтов это самый разумный вариант: история правок остаётся, но не превращается в бесконечный архив.