Очищення зайвих WP-Cron подій: як знайти та безпечно видалити

Що таке WP-Cron і чому в ньому накопичуються зайві події

WP-Cron — це внутрішній планувальник WordPress. Плагін або тема реєструє подію, вказуючи назву hook, час першого запуску та періодичність. Коли на сайт приходить запит, WordPress перевіряє, які завдання вже настав час виконати, і запускає відповідні callback-функції.

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

Наявність старої події не завжди означає аварійну проблему. Спочатку потрібно з’ясувати, кому належить hook, чи є компонент активним і чи справді завдання не потрібне.

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

Як переглянути список WP-Cron подій через WP-CLI

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

Для перегляду запланованих подій використайте:

wp cron event list --fields=hook,time,next_run_gmt,recurrence

На що звертати увагу у виведенні

Колонка hook містить технічну назву події. За нею часто можна визначити плагін або функціональний модуль. Поле next_run_gmt показує найближчий час запуску в часовій зоні GMT, тому не плутайте його з локальним часом сервера чи сайту.

Поле recurrence допомагає відрізнити періодичні події від одноразових. Якщо подія має минулий час запуску, це ще не доказ несправності: завдання могло чекати на наступний cron-запит або бути тимчасово заблокованим. Перевіряйте контекст, а не видаляйте всі прострочені записи без аналізу.

• запишіть назви підозрілих hook перед видаленням;
• порівняйте список із переліком активних плагінів і mu-plugin;
• перевірте, чи не належить подія WordPress Core, WooCommerce, темі або сервісу синхронізації;
• зверніть увагу на кількість однакових подій і частоту їх повторення.

Як визначити власника підозрілої події

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

Шукати потрібно виклики wp_schedule_event(), wp_schedule_single_event(), wp_schedule_single_event() та функції скасування wp_clear_scheduled_hook() або wp_unschedule_event(). На сервері з доступним grep приклад пошуку може виглядати так:

grep -R "wp_schedule_event\|wp_schedule_single_event\|wp_clear_scheduled_hook" wp-content/plugins wp-content/mu-plugins wp-content/themes

Перевірка через код і документацію

Якщо hook знайдено у файлах активного плагіна, не видаляйте його автоматично. Спочатку перевірте, чи не є це штатним завданням. Частина плагінів реєструє подію лише під час певної дії, а частина — під час кожного завантаження WordPress.

Особливо уважно перевіряйте події WooCommerce, резервного копіювання, кешування, розсилок, імпорту товарів та інтеграцій із зовнішніми API. Їх видалення може зупинити важливий процес, навіть якщо назва hook здається незрозумілою.

• деактивований плагін — сильна ознака, що його старі події можна прибрати, але перевірте залежності;
• mu-plugin потрібно аналізувати окремо, оскільки він не вимикається стандартним способом;
• якщо подія належить темі, вона може зникнути або з’явитися після зміни теми;
• подія, що повторно реєструється після кожного запиту, потребує виправлення коду, а не багаторазового видалення.

Як безпечно видалити зайву WP-Cron подію

Коли власника hook встановлено і ви впевнені, що завдання більше не потрібне, його можна видалити через WP-CLI. Параметр --all видаляє всі заплановані екземпляри події з таким hook, тому використовуйте його лише після перевірки.

wp cron event delete plugin_task --all

Видалення конкретного екземпляра

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

wp help cron event delete

Чого не варто робити

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

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

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

Перевірка після очищення

Після видалення запустіть завдання, термін виконання яких уже настав. Це допоможе побачити помилки активних компонентів і переконатися, що WordPress може обробляти поточний cron-розклад.

wp cron event run --due-now

Що перевірити після команди

Перегляньте виведення WP-CLI, журнали PHP та журнал вебсерверу. Якщо під час виконання з’являються помилки callback, зверніть увагу на назву hook і плагін, який її викликає.

Через короткий час повторно виведіть список подій. Якщо видалений hook не повернувся, очищення, найімовірніше, виконано успішно. Якщо він з’явився знову, активний код повторно реєструє його.

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

Що робити, якщо подія з’являється знову

Повторна поява події означає, що якийсь код її реєструє. Це може бути активний плагін, тема, mu-plugin або залишений фрагмент кастомного коду. Видалення через WP-CLI в такому випадку лише тимчасово прибирає результат, але не усуває причину.

Знайдіть виклик wp_schedule_event() або wp_schedule_single_event() і перевірте умови його виконання. Типова помилка — реєстрація періодичної події під час кожного завантаження WordPress без перевірки, чи вона вже існує. Інша проблема — відсутність wp_clear_scheduled_hook() під час деактивації плагіна.

Якщо після видалення плагіна його hook продовжує повертатися, перевірте mu-plugins, drop-in-файли, код теми та залишки кастомної інтеграції. У складних випадках тимчасово деактивуйте підозрілі компоненти на тестовій копії сайту й порівняйте список подій.

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

Коли варто налаштувати системний cron

На сайтах із великим трафіком або великою кількістю завдань запуск WP-Cron через відвідування може бути нестабільним: події виконуються із затримкою або кілька завдань стартують одночасно. У такому випадку часто вимикають автоматичний запуск WP-Cron під час вебзапитів і налаштовують системний cron на сервері.

Це не замінює очищення зайвих подій. Системний cron лише забезпечує регулярний запуск планувальника, але не виправляє неправильну реєстрацію hook, дублікати чи залишки видалених плагінів. Конкретний спосіб налаштування залежить від хостингу, доступу до SSH і конфігурації WordPress.

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