Очистка старых ревизий WordPress через WP-CLI

Что такое ревизии WordPress и зачем их удалять

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

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

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

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

Проверьте сайт и подготовьте резервную копию

Перед очисткой убедитесь, что WP-CLI запускается из корневой директории нужного сайта WordPress. Проверить это можно командой wp core is-installed. Если на сервере размещено несколько сайтов, добавьте параметр --path или выполняйте команды из правильной директории.

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

Если сайт работает в режиме Multisite, проверьте, какой именно сайт и какие таблицы будет обрабатывать команда. Не запускайте очистку с неправильным параметром --url или --path.

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

wp core is-installed
wp db export wordpress-before-revisions-cleanup.sql

Как посчитать и проверить ревизии

Сначала определите общее количество записей типа revision. Наиболее совместимый вариант — получить идентификаторы и посчитать их в shell. Если ваша версия WP-CLI поддерживает формат count, можно использовать более короткую команду.

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

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

wp post list --post_type=revision --format=ids | wc -w
wp post list --post_type=revision --format=count
wp post list --post_type=revision --fields=ID,post_parent,post_date,post_title --format=table --number=20

Пакетное удаление старых ревизий через WP-CLI

Для очистки используйте wp post delete с параметром --force. Он удаляет ревизии без перемещения в корзину. Для ревизий это обычно необходимо, поскольку промежуточное перемещение в корзину не дает практической пользы, но может создать дополнительные записи.

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

Параметр -r команды xargs доступен в GNU-окружении, которое обычно используется в Linux. В некоторых BSD-системах, включая macOS, параметр -r может отсутствовать. В таком случае проверьте man xargs или используйте эквивалентный сценарий, который не запускает команду для пустого списка.

• не удаляйте записи прямым SQL-запросом без понимания связанных данных и хуков WordPress;
• при первом запуске используйте небольшой тестовый пакет и проверьте результат;
• без необходимости не прерывайте процесс, если на сайте одновременно работают редакторы.

wp post list --post_type=revision --format=ids \
| xargs -r -n 100 wp post delete --force

Как выполнить тестовую очистку

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

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

wp post list --post_type=revision --format=ids --number=10 \
| xargs -r -n 10 wp post delete --force

Что проверить после очистки

После завершения команды еще раз посчитайте ревизии и убедитесь, что WP-CLI не вывел ошибок доступа, подключения к базе данных или обработки отдельных записей. Затем проверьте несколько записей на сайте и в административной части.

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

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

• повторно проверьте количество ревизий;
• откройте несколько записей и страниц во внешней части сайта;
• проверьте сохранение тестового изменения;
• просмотрите логи WP-CLI и PHP, если команда завершилась с ошибкой;
• при необходимости отдельно запланируйте оптимизацию таблиц после создания резервной копии.

wp post list --post_type=revision --format=count
wp post list --post_type=revision --format=ids | wc -w

Как ограничить накопление новых ревизий

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

Размещайте эту строку до комментария о завершении редактирования wp-config.php. После изменения проверьте, что файл не содержит синтаксических ошибок, а сайт и редактор открываются корректно.

Не устанавливайте значение 0 только для того, чтобы остановить рост базы данных. Такая настройка может фактически лишить редакторов возможности восстанавливать предыдущие версии. Если ревизии нужны, лучше задать небольшое положительное число. Настройка также не удаляет уже накопленные записи — их нужно очистить отдельно.

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

define('WP_POST_REVISIONS', 5);

Типичные ошибки при очистке ревизий

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

Вторая ошибка — отсутствие резервной копии. Даже если команда должна удалять только записи типа revision, ошибка в параметрах или сторонний код могут иметь непредвиденные последствия.

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

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