База WordPress роздулася, адмінка гальмує, а бекап важить як архів середнього сайту? Швидше за все, винні ревізії, чернетки кожного збереження, які рушій накопичує роками.

Одна сторінка за час життя набирає десятки правок. Помножте на сотні постів і отримаєте гігабайти сміття в wp_posts. Гірше того: ревізії зберігаються в тій самій таблиці, що й опублікований контент, тому кожен зайвий запис уповільнює запити.

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

💡 Швидкий огляд:

• WP-Sweep, найбезпечніший шлях: плагін видаляє ревізії штатними функціями WordPress, без прямих запитів до бази.
• wp-config.php, три рядки коду повністю вимикають або обмежують збереження чернеток на рівні рушія.
• SQL-запит, миттєве очищення одним запитом; потребує повного бекапу бази перед запуском.
• Інтервал автозбереження, не видаляє вже накопичене, але радикально уповільнює приріст ревізій у майбутньому.

Крок 1: Видалити ревізії плагіном WP-Sweep

Найпростіший і найбезпечніший спосіб для тих, хто не хоче чіпати код. WP-Sweep викликає штатні функції WordPress (wp_delete_post_revision), плагін не пише сирі запити, тому ризик пошкодити базу мінімальний.

Встановлення стандартне:

• Перейдіть у Плагіни → Додати новий.
• Знайдіть WP-Sweep, натисніть Встановити та Активувати.
• Відкрийте Інструменти → Sweep.
• Знайдіть рядок Revisions і натисніть кнопку Sweep.

Плагін покаже, скільки ревізій видалено і скільки місця звільнено. Крім ревізій WP-Sweep вміє чистити спам-коментарі, чернетки автозбереження, невикористовувані терміни таксономій та мета-поля-сироти, усе через рідне API WordPress.

🔗 WP-Sweep на WordPress.org

Крок 2: Вимкнути ревізії через wp-config.php

Якщо ревізії не потрібні в принципі, вимкніть їх одним рядком. Знайдіть у корені сайту файл wp-config.php і додайте код **до рядка **/* That's all, stop editing! */:

1
define( 'WP_POST_REVISIONS', false );

Після цього WordPress перестане зберігати чернетки при кожному автозбереженні та натисканні «Оновити». У базі залишиться тільки остання версія поста.

Зверніть увагу: уже накопичені ревізії цей рядок не видаляє, він лише запобігає появі нових. Наявне сміття чистіть Кроком 1 або бонусним SQL-запитом нижче.

Щоб знову ввімкнути ревізії, замініть false на true або просто видаліть рядок.

Крок 3: Обмежити кількість ревізій

Повне вимкнення підходить не всім. Якщо редакція з трьох осіб править один пост і потрібна історія змін, краще не вимикати ревізії, а обмежити їхню кількість.

Додайте в wp-config.php перед рядком /* That's all, stop editing! */:

1
define( 'WP_POST_REVISIONS', 3 );

Число 3 означає: WordPress зберігає максимум три останні версії кожного поста. Четверта редакція затирає найстарішу, база не розростеться.

Для більшості сайтів трьох ревізій вистачає із запасом. Якщо публікуєте довгі лонгріди з десятками ітерацій, поставте 5 або 10. Обмеження немає, можна вказати будь-яке ціле число.

Крок 4: Змінити інтервал автозбереження

Типово WordPress зберігає чернетку кожні 60 секунд. При активній роботі над постом це створює десятки ревізій за годину. Інтервал можна розсунути, тоді автозбережень стане менше, а база зростатиме повільніше.

Додайте в wp-config.php:

1
define( 'AUTOSAVE_INTERVAL', 600 );

Значення 600 — це секунди (10 хвилин). За такого налаштування чернетка записується в базу раз на 10 хвилин замість кожної хвилини. Мінімум, який приймає WordPress,, 60 секунд; рекомендований максимум, 3600 (година).

Цей прийом не чистить наявні ревізії, але радикально скорочує приріст нових. Комбінуйте його з лімітом із Кроку 3, отримаєте чисту базу без регулярного ручного очищення.

Бонус: видалення ревізій SQL-запитом напряму

Найшвидший шлях, якщо чистка плагіном з якихось причин не підходить. Увага: запит незворотний. Перед запуском зробіть повний бекап бази даних через phpMyAdmin, WP-CLI або плагін резервного копіювання.

Спочатку безпечний dry-run: подивіться, скільки ревізій буде зачеплено, не видаляючи їх:

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

Якщо префікс таблиць у вас не wp_, замініть на свій (подивіться в wp-config.php, рядок $table_prefix).

Коли переконалися, що цифра адекватна, виконуйте видалення:

1
DELETE FROM wp_posts WHERE post_type = 'revision';

Запит видаляє всі ревізії з усіх постів одним махом. Після цього база стане легшою миттєво, особливо на старих сайтах із сотнями сторінок.

Що запит не чіпає: опубліковані пости, чернетки (post_status='draft'), сторінки, вкладення, меню, кошик. Він націлений суворо на записи з post_type='revision', рушій використовує цей тип тільки для зберігання версій.

⁉️🤔 Часті питання

Ревізії точно не впливають на швидкість сайту?

Впливають, але опосередковано. Самі ревізії не завантажуються на фронті, вони лежать у wp_posts і збільшують загальний розмір таблиці. На сайті з 10 000+ записів кожна зайва тисяча рядків уповільнює запити WP_Query, особливо якщо немає об'єктного кешу (Redis). Після чистки ревізій різниця помітна в адмінці та при збереженні постів.

Чи безпечно видаляти ревізії плагіном?

WP-Sweep безпечний саме тому, що не пише сирі SQL-запити. Він смикає wp_delete_post_revision(), ту саму функцію, яку WordPress викликає при штатному видаленні чернетки. Тим не менш правило «зроби бекап перед будь-якою операцією з базою» ніхто не скасовував.

Що буде з автозбереженнями після вимкнення ревізій?

Автозбереження продовжать працювати, вони технічно окремий механізм. WordPress зберігає один автосейв на пост (останній), і він перезаписується, а не накопичується. Вимкнення ревізій через WP_POST_REVISIONS на автозбереження не впливає. А от зміна AUTOSAVE_INTERVAL напряму керує ними.

Чи можна видалити ревізії тільки для певних типів постів?

Так, через фільтр wp_revisions_to_keep. Додайте в functions.php теми або в Code Snippets:

1
add_filter( 'wp_revisions_to_keep', function( $num, $post ) {
2
    if ( 'product' === $post->post_type ) {
3
        return 0; // не хранить ревизии товаров WooCommerce
4
    }
5
    return $num;
6
}, 10, 2 );

Цей код вимикає ревізії тільки для товарів, залишаючи стандартну поведінку для постів і сторінок. Для масового видалення вже накопичених ревізій конкретного типу, тільки SQL з умовою по post_parent.

Perfmatters** замінює WP-Sweep?**

Perfmatters, комерційний плагін продуктивності, і керування ревізіями там лише одна з 40+ функцій. Він уміє обмежувати кількість ревізій (аналог WP_POST_REVISIONS) і чистити їх за розкладом. Але якщо потрібна тільки чистка ревізій, WP-Sweep повністю безплатний і справляється не гірше. Perfmatters має сенс брати, коли паралельно потрібні відкладене завантаження, вимкнення емодзі-скриптів та інші тонкі налаштування продуктивності.

Чи потрібно чистити ревізії на новому сайті?

На свіжому сайті з десятком постів ревізії займають кілобайти, сенсу в чистці немає. Але заведіть звичку: якщо плануєте вести блог активно, поставте ліміт WP_POST_REVISIONS у 3-5 прямо зараз. Потім не доведеться розбирати завали.

Що ставити під вашу задачу?

Коротка матриця:

• Хочете безпечно і швидко, без коду → WP-Sweep (Крок 1) + обмеження ревізій до 3 (Крок 3).
• Ревізії не потрібні взагалі, працюєте один → вимкніть через WP_POST_REVISIONS, false (Крок 2).
• **База величезна, плагін гальмує на **хостингу → SQL-запит із бонусного розділу (суворо після бекапу).
• Уже чисто, хочете зберегти порядок → ліміт ревізій 3-5 (Крок 3) + інтервал автозбереження 300-600 секунд (Крок 4).

Витратьте п'ять хвилин зараз, і база більше не роздуватиметься роками. А якщо після чистки ревізій сайт усе ще гальмує, перевірте інші способи прискорити WordPress: кешування запитів і легковажна тема часто дають більший приріст, ніж видалення ревізій.