Очищення старих ревізій 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 може перевищити ліміт довжини командного рядка. Тому IDs передаються пакетами, наприклад по 100 значень.

Команда xargs -r доступна в 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, помилка в параметрах або сторонній код може мати непередбачені наслідки.

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

• не плутайте ревізії з опублікованими записами;
• не використовуйте один великий список IDs без пакетування;
• не видаляйте дані прямим SQL, якщо не перевірені всі залежності;
• не вважайте WP_POST_REVISIONS заміною резервного копіювання;
• не запускайте команду з --allow-root без реальної потреби та розуміння наслідків.