Как найти и удалить старые редакции записей в WordPress без потери данных

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

Удалять ревизии можно, но делать это нужно не «вслепую», а с пониманием, что именно хранится, как не снести полезные автосохранения и как ограничить рост проблемы на будущее.

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

Ревизии — это не ошибка WordPress, а штатный механизм. Проблема начинается, когда их слишком много для объема и режима работы сайта. На практике это проявляется так:

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

Что важно не перепутать

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

Диагностика: сколько ревизий уже накопилось

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

SELECT post_type, COUNT(*) AS total
FROM wp_posts
WHERE post_type = 'revision'
GROUP BY post_type;

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

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;

В админке это обычно не видно, поэтому ориентироваться только на интерфейс нельзя. Для проверки объема базы удобнее смотреть не «ощущения», а конкретные цифры до и после очистки.

Какой способ выбрать: плагин, код или WP-CLI

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

Пошаговое решение: безопасная очистка старых ревизий

Шаг 1. Сделайте резервную копию

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

Шаг 2. Ограничьте число ревизий на будущее

Чтобы проблема не возвращалась, можно ограничить количество ревизий для всех записей. Для этого в wp-config.php добавляют константу WP_POST_REVISIONS. Например, оставить последние 5 версий:

define( 'WP_POST_REVISIONS', 5 );

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

Шаг 3. Удалите уже накопленные старые ревизии

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

DELETE p1
FROM wp_posts p1
INNER JOIN wp_posts p2
  ON p1.post_parent = p2.post_parent
 AND p1.post_type = 'revision'
 AND p2.post_type = 'revision'
 AND p1.post_date < p2.post_date
LEFT JOIN wp_posts p3
  ON p1.post_parent = p3.post_parent
 AND p3.post_type = 'revision'
 AND p3.post_date > p1.post_date
WHERE p3.ID IS NOT NULL;

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

Шаг 4. Очистите «хвосты» в базе

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

Вариант через WP-CLI

Если есть SSH-доступ, WP-CLI удобнее ручного SQL: меньше шансов ошибиться в запросе и проще повторять процедуру. Для удаления ревизий можно использовать стандартную команду WordPress:

wp post delete $(wp post list --post_type='revision' --format=ids) --force

Но перед этим лучше сначала посмотреть, что именно будет удалено:

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

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

Проверка результата после внедрения

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

• Откройте несколько записей в редакторе и убедитесь, что текущая версия сохраняется нормально.
• Проверьте, что в блоке «Ревизии» остались только нужные версии или их количество уменьшилось.
• Снова выполните SQL-запрос на подсчет ревизий и сравните результат с исходным.
• Посмотрите размер базы и время ответа админки, если до этого были заметные задержки.

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

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

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

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

Удаляют ревизии без бэкапа

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

Путают ревизии и автосохранения

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

Используют слишком агрессивный SQL

Опасно удалять записи без фильтра по post_type = 'revision'. В этом случае можно задеть обычные посты, страницы или вложения. Любой запрос сначала проверяйте на SELECT, а не на DELETE.

Ожидают, что очистка ускорит все сразу

Если сайт тормозит из-за тяжелой темы, медленного хостинга или неудачных запросов плагинов, удаление ревизий даст только частичный эффект. Это полезная профилактика, но не универсальное лечение.

Практические советы по безопасности и производительности

Чтобы ревизии не превращались в постоянную проблему, лучше сразу встроить несколько ограничений в рабочий процесс:

• храните ограниченное число ревизий через wp-config.php;
• не запускайте массовую очистку в часы пик;
• проверяйте размер базы до и после обслуживания;
• если на сайте несколько редакторов, согласуйте политику редактирования и хранения истории;
• не ставьте сомнительные плагины для «ускорения» без понимания, что они удаляют.

Если нужен более широкий контроль над дублями, служебными мета-данными и мусором в базе, иногда удобнее использовать специализированные инструменты очистки, например Clearfy Pro от WPShop: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала стоит понять, какие именно данные вы собираетесь удалять и как потом проверить результат.

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