Безпечне очищення WordPress Transients через WP-CLI

Що таке WordPress Transients і чому вони накопичуються

Transient — це тимчасове значення з терміном дії. WordPress зберігає його під окремим ключем і повертає плагіну або темі, поки воно не стане простроченим. Наприклад, таким способом можуть кешуватися курси валют, відповіді зовнішнього API, списки товарів, результати складних запитів або дані віджета.

За відсутності persistent object cache transients зазвичай зберігаються у таблиці wp_options. Для кожного значення WordPress може створювати основний запис і службовий запис із часом завершення дії. Велика кількість таких записів збільшує розмір таблиці, ускладнює обслуговування бази та може додавати зайві операції під час роботи з options.

Важливо: сам факт наявності великої кількості transients не завжди означає проблему. Частина з них може бути актуальною, а причиною уповільнення — конкретний плагін, помилка кешування або надто часте створення унікальних ключів.

• кешування відповідей зовнішніх сервісів і API;
• тимчасове збереження результатів дорогих SQL-запитів;
• кешування фрагментів сторінки або даних віджетів;
• зберігання службових значень під час роботи плагінів.

Чому не варто видаляти Transients прямим SQL

Пряме видалення рядків із wp_options може виглядати швидким рішенням, але воно обходить API WordPress. У результаті можна видалити актуальні значення, службові ключі або записи, які плагін ще використовує. Окремий ризик — неправильний SQL-фільтр, що зачепить не лише transients, а й інші налаштування сайту.

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

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

• не видаляйте всі записи за шаблоном _transient_% без перевірки;
• не запускайте очищення на робочому сайті без резервної копії або можливості відновлення;
• не плутайте transients зі звичайними налаштуваннями плагінів у wp_options.

Підготовка до очищення через WP-CLI

Перед командою перевірте, що WP-CLI працює в каталозі встановлення WordPress і має доступ до потрібного сайту та бази даних. На сервері з кількома сайтами важливо не переплутати документ-рут або конфігурацію конкретного середовища.

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

До очищення корисно зафіксувати базові показники: час відповіді, помилки PHP, навантаження на сервер і кількість записів. Так буде зрозуміло, чи справді процедура дала результат, а не просто змінила симптом.

• перевірте доступ до SSH і працездатність команди wp;
• переконайтеся, що команду запускають для правильного WordPress-сайту;
• за можливості заплануйте операцію на період невисокого навантаження;
• попередьте команду, якщо після очищення очікується тимчасове зростання кількості API-запитів.

wp --info
wp core is-installed
wp transient list --fields=name,expiration --format=table

Як видалити лише прострочені Transients

Для стандартного обережного очищення використовуйте команду, яка видаляє тільки transients із завершеним терміном дії:

Це кращий перший крок, якщо ви бачите накопичення тимчасових записів, але не маєте причин скидати весь кеш. Актуальні значення залишаться доступними, тому кількість повторних запитів до API та перебудови кешу буде меншою.

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

• запускайте команду з правами користувача, який має доступ до потрібного WordPress;
• не переривайте процес без потреби на великій базі;
• після очищення перевірте головні сторінки, форми, кошик, авторизацію та функції, що залежать від API.

wp transient delete --expired

Коли допустиме повне очищення Transients

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

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

Не запускайте повне очищення за фіксованим cron-розкладом без аналізу. Якщо видаляти кеш щогодини або щодня, система постійно працюватиме в режимі перебудови, а не використовуватиме вже підготовлені значення. Це може збільшити навантаження на PHP, MySQL і сторонні API.

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

wp transient delete --all

Що змінюється при використанні Redis або іншого object cache

Якщо на сервері налаштовано Redis, Memcached або інший persistent object cache, transients можуть оброблятися не так, як у стандартній схемі зі збереженням лише в MySQL. Частина даних може перебувати в об'єктному кеші, а база даних може не містити повної картини.

Команда wp transient delete працює через WordPress API, тому це безпечніший варіант, ніж ручне очищення таблиць. Однак конкретна поведінка залежить від реалізації object cache та конфігурації плагіна. Не варто автоматично очищати весь Redis командою на кшталт FLUSHALL: це може стерти кеш інших сайтів, сервісів або застосунків на тому самому сервері.

Якщо після видалення transients значення продовжують повертатися, перевірте налаштування object cache, префікси ключів і логи. Іноді старі дані залишаються в окремому шарі кешування, а іноді плагін створює їх знову під час першого запиту.

• уточніть, чи підключений persistent object cache;
• не очищайте весь Redis без підтвердження меж конкретного сайту;
• перевірте, чи не працюють паралельно page cache, CDN або кеш на рівні проксі;
• аналізуйте логи PHP і Redis, якщо результат відрізняється від очікуваного.

wp plugin list --status=active
wp transient list --format=count

Перевірка результату та пошук причини повторного накопичення

Очищення transients — це не виправлення причини, через яку вони з'явилися. Якщо після процедури база знову швидко зростає, знайдіть плагін або тему, що створює записи. Корисними сигналами є однаковий префікс ключів, велика кількість унікальних назв і постійне створення записів із коротким терміном дії.

Перевірте журнал PHP на помилки тайм-аутів, проблеми API та повторні запити. Для магазинів і сайтів із зовнішніми інтеграціями окремо контролюйте ліміти API: після повного очищення багато одночасних відвідувачів можуть спричинити хвилю однакових запитів.

Результат варто оцінювати не лише за кількістю видалених записів. Важливіші показники — стабільність функцій сайту, час відповіді, навантаження на PHP і базу, кількість помилок та швидкість повторного заповнення кешу.

• порівняйте стан сайту до і після очищення;
• перевірте сторінки, які використовують зовнішні інтеграції;
• подивіться, чи не зростає кількість однакових запитів після скидання кешу;
• якщо transients повертаються надто швидко, перевірте код або налаштування відповідного плагіна.

Типові помилки під час очищення

Найпоширеніша помилка — виконати повне очищення замість видалення лише прострочених значень. Для звичайного обслуговування починайте з --expired, а --all залишайте для обґрунтованих випадків.

Друга помилка — очікувати миттєвого прискорення сайту. Якщо проблема пов'язана з повільним плагіном, неоптимальним запитом або перевантаженим API, видалення transients лише прибере кеш і може тимчасово збільшити навантаження.

Третя помилка — налаштувати регулярний cron, який безумовно видаляє всі transients. Автоматизувати можна очищення прострочених даних, але навіть для нього потрібно контролювати ефект і не запускати процес частіше, ніж це виправдано фактичним накопиченням.

• не використовуйте прямий DELETE у wp_options як перший метод;
• не очищайте весь object cache без розуміння його меж;
• не ігноруйте резервні копії та журнали;
• не оцінюйте оптимізацію тільки за розміром таблиці wp_options.