Если сайт давно живёт на WordPress, база часто разрастается не из-за контента, а из-за ревизий, автосохранений и мусорных записей после правок. Это не всегда критично, но на небольших и средних проектах такие данные мешают обслуживанию: бэкапы становятся тяжелее, запросы к wp_posts и wp_postmeta — медленнее, а в редакторе появляется лишний шум.
Полностью отключать ревизии и автосохранение вслепую не стоит. У этих механизмов есть практическая польза: ревизии помогают откатить неудачную правку, а автосохранение спасает черновик при сбое браузера. Задача обычно не в том, чтобы убрать всё, а в том, чтобы оставить рабочий минимум.
Когда это действительно нужно
Сначала стоит понять, есть ли проблема вообще. На живом сайте симптомы обычно такие:
- в таблице
wp_postsмного записей с типомrevision; - при редактировании одной страницы в админке список ревизий растёт слишком быстро;
- бэкап базы заметно увеличился без роста контента;
- на старых хостингах админка начинает тормозить при открытии крупных записей;
- редакторы жалуются, что сохраняют одну статью по 10–20 раз и получают десятки ревизий.
Как быстро проверить состояние базы
Если есть доступ к phpMyAdmin или консоли MySQL, посмотрите количество ревизий и общий объём записей:
SELECT post_type, COUNT(*) AS cnt
FROM wp_posts
GROUP BY post_type
ORDER BY cnt DESC;Если ревизий много, можно оценить, сколько места они занимают в базе. Для этого полезно посмотреть таблицу wp_posts через интерфейс хостинга или выполнить более детальный запрос уже под конкретную задачу. Важно не гадать по ощущениям: сначала измерьте, потом меняйте настройки.
Что лучше: плагин, код или настройка в wp-config.php
Есть три рабочих подхода. Выбор зависит от того, нужен ли вам быстрый интерфейс для админов или достаточно точечной настройки в коде.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
Константы в wp-config.php | Нужно ограничить ревизии на уровне сайта | Просто, без лишних зависимостей | Требует доступа к файлам |
| Код в теме или MU-плагине | Нужна гибкая логика | Можно управлять точнее | Нужно аккуратно поддерживать |
| Плагин оптимизации | Нужен интерфейс и дополнительные функции очистки | Удобно для редакторов и админов | Лишний слой настроек, не всегда нужен |
Если у вас уже стоит плагин для технической чистки сайта, например Clearfy Pro, проверьте, нет ли там готовых настроек для ревизий и автосохранения. Но если задача точечная, часто проще обойтись штатными средствами WordPress.
Пошаговое решение: ограничить ревизии и настроить автосохранение
Шаг 1. Ограничьте количество ревизий
Самый безопасный вариант — не отключать ревизии полностью, а ограничить их число. Добавьте в wp-config.php перед строкой /* That's all, stop editing! */:
define('WP_POST_REVISIONS', 5);Это оставит последние 5 ревизий для записей и страниц. Для большинства сайтов этого достаточно: есть куда откатиться, но база не раздувается бесконечно.
Если вам нужно полностью отключить ревизии, можно поставить false:
define('WP_POST_REVISIONS', false);Но такой вариант я бы использовал только на очень простых сайтах, где контент редактируют редко и у команды есть отдельный процесс согласования правок. Иначе вы сами себе уберёте страховку.
Шаг 2. Настройте интервал автосохранения
По умолчанию WordPress довольно часто делает автосохранение. На слабом хостинге или при медленном соединении это может создавать лишнюю нагрузку и раздражать редакторов. Интервал можно увеличить:
define('AUTOSAVE_INTERVAL', 120);Значение задаётся в секундах. В примере автосохранение будет происходить раз в 2 минуты. Это не отключение, а более спокойный режим. Для большинства редакционных сайтов это разумнее, чем полное выключение.
Шаг 3. Очистите старые ревизии из базы
Ограничение ревизий не удалит уже накопленные записи. Сначала сделайте резервную копию базы, потом удалите старые ревизии SQL-запросом:
DELETE FROM wp_posts
WHERE post_type = 'revision';Если на сайте есть сложные интеграции, кастомные типы записей или нестандартные плагины, сначала проверьте, не завязаны ли они на историю изменений. В обычной установке WordPress это безопасная операция, но бэкап обязателен.
Шаг 4. Проверьте, не мешает ли тема или плагин
Иногда проблема не в ревизиях, а в том, что сторонний плагин сам создаёт дополнительные записи или дублирует сохранения. Если после настройки число ревизий всё равно растёт слишком быстро, временно отключите плагины, связанные с редактором, автосохранением, формами и кастомными полями, и проверьте поведение на чистом шаблоне.
Как проверить, что решение сработало
После изменений не ограничивайтесь визуальной проверкой в админке. Нужны конкретные признаки:
- при редактировании записи создаётся не бесконечная цепочка ревизий, а заданный лимит;
- в
wp_postsперестаёт быстро расти число записей с типомrevision; - бэкап базы становится меньше после очистки старых ревизий;
- редактор WordPress по-прежнему сохраняет черновик и не теряет изменения при обновлении страницы;
- в консоли браузера нет ошибок, связанных с автосохранением или REST API.
Проверить лимит можно простым способом: откройте запись, внесите несколько правок подряд и посмотрите, сколько ревизий появилось в блоке истории. Если их больше, чем вы задали, значит настройка не применяется — чаще всего из-за неверного места в wp-config.php или конфликта с кодом в теме.
Частые ошибки и как их исправить
Отключили ревизии полностью и потеряли удобный откат
Это самая частая ошибка. На практике через неделю-две кто-то обязательно захочет вернуть старый вариант текста, а откатываться уже некуда. Если сайт не совсем статичный, лучше ограничить ревизии, а не убирать их полностью.
Поставили слишком длинный интервал автосохранения
Когда автосохранение делают раз в 5–10 минут, редакторы начинают терять правки при сбое вкладки или зависании браузера. Для контентных сайтов это плохой компромисс. Если нагрузка — реальная проблема, сначала ограничьте ревизии и очистите базу, а не ломайте защиту от потери текста.
Удалили ревизии без бэкапа
SQL-запрос на удаление ревизий выглядит просто, но ошибка в префиксе таблиц или случайный запуск не в той базе создают лишние проблемы. Перед очисткой проверьте имя таблицы, сделайте экспорт базы и только потом запускайте удаление.
Редактировали не тот файл
Константы WP_POST_REVISIONS и AUTOSAVE_INTERVAL должны быть в wp-config.php, а не в functions.php. Если добавить их в тему, настройка может не примениться вовремя или сломаться после обновления шаблона.
Практические советы по безопасности и производительности
Если сайт рабочий, не ограничивайтесь одной настройкой. После чистки ревизий полезно проверить ещё несколько вещей:
- убедиться, что регулярные бэкапы базы уже настроены и хранятся отдельно от сайта;
- не чистить ревизии прямо на продакшене без предварительной копии;
- не ставить слишком агрессивные значения автосохранения для редакторов, которые работают с длинными текстами;
- после удаления ревизий оптимизировать таблицу
wp_postsсредствами хостинга или MySQL, если это уместно; - если сайт большой, выполнять очистку в окно низкой нагрузки.
Для админов, которым нужен более широкий набор технических настроек, удобнее использовать один инструмент для чистки сайта и отключения лишнего. Но даже в этом случае не стоит полагаться только на плагин: базовые параметры в wp-config.php проще контролировать и легче переносить между окружениями.
Минимальный рабочий вариант для большинства сайтов
Если нужен короткий и безопасный рецепт, используйте такой порядок:
- сделать бэкап базы;
- ограничить ревизии до 5;
- увеличить автосохранение до 120 секунд;
- удалить старые ревизии из базы;
- проверить редактор и количество новых ревизий после нескольких правок.
Такой подход обычно решает проблему без лишнего риска. Вы не отключаете важные механизмы WordPress, а просто приводите их к разумному режиму работы.