WP-Cron у WordPress запускається не за розкладом операційної системи, а під час заходу відвідувача на сайт: файл wp-cron.php смикається при кожному завантаженні сторінки і перевіряє, чи не час виконати відкладене завдання. На сайті з рідкісними візитами публікація за розкладом і розсилки запізнюються на години. Розберемо, як це виправити системним cron.
Чому WP-Cron запізнюється або не спрацьовує взагалі
Псевдокрон WordPress живий, лише поки є трафік: немає візиту — немає перевірки завдань. Друга причина збоїв — спільний хостинг з агресивним кешуванням сторінок: кешувальний плагін віддає збережену HTML-копію і не пропускає запит до PHP, а отже і до wp-cron.php. Третя причина — заблокований на рівні сервера вихідний self-запит, через який WordPress не може сам себе смикнути по HTTP.
Як перевірити поточний стан завдань
Список запланованих завдань і їх точний час зручно дивитися через WP-CLI, якщо він доступний на хостингу.
wp cron event list --fields=hook,next_run_relative,recurrence
Якщо колонка next_run_relative показує від'ємне значення на кшталт «-3 hours», завдання прострочене і чекає наступного візиту відвідувача, щоб виконатися.
Як вимкнути вбудований псевдокрон
Вимкнення виконується однією константою в wp-config.php — додайте рядок перед позначкою «That's all, stop editing!».
<?php
define('DISABLE_WP_CRON', true);
Після цієї правки WordPress перестає перевіряти завдання під час кожного візиту, але самі завдання з бази нікуди не зникають — їхній запуск просто чекає зовнішнього тригера.
Як налаштувати системний cron замість псевдокрона
Завдання потрібно передати планувальнику самої операційної системи. Додайте рядок через crontab -e від імені користувача, під яким працює сайт.
*/5 * * * * curl -s https://site.example/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Запуск раз на 5 хвилин — розумний компроміс для більшості сайтів: розсилки і публікації за розкладом не запізнюються помітно, а навантаження на сервер лишається невеликим. Якщо на сервері є WP-CLI, виклик через нього надійніший — обходить HTTP-шар і не залежить від кешу сторінок.
*/5 * * * * cd /var/www/site.example/public_html && wp cron event run --due-now --quiet
Як обрати інтервал для різних завдань
| Завдання | Рекомендований інтервал | Наслідок запізнення |
|---|---|---|
| Відкладена публікація запису | 1–5 хвилин | матеріал виходить пізніше плану |
| Планова розсилка листів | 5 хвилин | листи йдуть пачкою із затримкою |
| Очищення тимчасових даних плагінів | 15–30 хвилин | росте розмір бази даних |
| Перевірка оновлень ядра і плагінів | 1 раз на годину | затримка сповіщення про оновлення |
Часті помилки під час переходу на системний cron
Забута константа DISABLE_WP_CRON призводить до дублювання: завдання виконуються і за системним розкладом, і за старим псевдокроном під час візиту, через що листи розсилки можуть піти двічі. Друга помилка — cron налаштовано на сервері, але на сайті увімкнено LiteSpeed Cache чи схожий плагін, який кешує сам wp-cron.php як звичайну сторінку — виключіть цей шлях із правил кешу явно. Повний список дій під час зміни адреси і пов'язаних із cron завдань перенесення описано в статті про зміну домену WordPress.
Перевірити, що перенесення спрацювало, просто: через годину після налаштування системного cron знову виконайте wp cron event list і переконайтеся, що час у колонці next_run_relative зсувається вперед навіть без візитів на сайт. Для керування і діагностики завдань корисні й інші команди — добірка зібрана в статті про WP-CLI.
Підсумок
- WP-Cron за замовчуванням запускається лише під час візиту відвідувача, тому на тихих сайтах завдання запізнюються.
- Вимкнути псевдокрон можна константою
DISABLE_WP_CRONуwp-config.php. - Завдання потрібно передати в crontab операційної системи з інтервалом 5 хвилин через curl або напряму через WP-CLI.
- Після перенесення перевірте, що завдання не виконуються двічі через забуту константу.
- Кешувальні плагіни варто налаштувати так, щоб вони не віддавали
wp-cron.phpіз кешу.