# WP-Cron не працює: перенесення завдань на системний cron

> WP-Cron не запускається на сайті з низькою відвідуваністю — вимикаємо вбудований псевдокрон і переносимо завдання WordPress на системний cron.

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](https://www.zevshost.net/uk/kb/wordpress-litespeed-cache/) чи схожий плагін, який кешує сам `wp-cron.php` як звичайну сторінку — виключіть цей шлях із правил кешу явно. Повний список дій під час зміни адреси і пов'язаних із cron завдань перенесення описано в статті про [зміну домену WordPress](https://www.zevshost.net/uk/kb/wordpress-smena-domena-url/).

Перевірити, що перенесення спрацювало, просто: через годину після налаштування системного cron знову виконайте `wp cron event list` і переконайтеся, що час у колонці `next_run_relative` зсувається вперед навіть без візитів на сайт. Для керування і діагностики завдань корисні й інші команди — добірка зібрана в статті про [WP-CLI](https://www.zevshost.net/uk/kb/wp-cli-commands/).

## Підсумок

- WP-Cron за замовчуванням запускається лише під час візиту відвідувача, тому на тихих сайтах завдання запізнюються.
- Вимкнути псевдокрон можна константою `DISABLE_WP_CRON` у `wp-config.php`.
- Завдання потрібно передати в crontab операційної системи з інтервалом 5 хвилин через curl або напряму через WP-CLI.
- Після перенесення перевірте, що завдання не виконуються двічі через забуту константу.
- Кешувальні плагіни варто налаштувати так, щоб вони не віддавали `wp-cron.php` із кешу.

---

Джерело: https://www.zevshost.net/uk/kb/wordpress-cron-sistemnyy/