# Заміна WP-Cron

Queuety може замінити вбудовану систему WordPress cron. Після ввімкнення виклики `wp_schedule_event()` перехоплюються й спрямовуються через планувальник Queuety замість стандартного механізму WP-Cron. Події має обробляти воркер Queuety, який виконується незалежно від трафіку сайту.

> **Поточне обмеження:** міст створює розклади Queuety, але у воркера немає обробника для завдань `__queuety_cron_{hook}`, які вони створюють, тому початкові зворотні виклики WordPress ніколи не виконуються. Кожне завдання завершується помилкою, повторюється зі збільшенням інтервалу й зрештою переміщується до відкладених ([#9](https://github.com/inline0/queuety/issues/9)). Не вмикайте міст на сайті, де мають виконуватися події cron, доки це не буде виправлено.

## Увімкнення заміни

Викличте `Queuety::replace_wp_cron()` на початку ініціалізації плагіна або теми:

```php
use Queuety\Queuety;

Queuety::replace_wp_cron();
```

Зазвичай це викликають в основному файлі плагіна або в хуку `plugins_loaded`. Виклик має відбутися після завантаження WordPress (плагін має бути активним).

## Що перехоплюється

Міст cron підключається до трьох фільтрів WordPress:

| Функція WordPress | Фільтр, до якого підключено хук | Поведінка |
|---|---|---|
| `wp_schedule_event()` | `pre_schedule_event` | Створює розклад Queuety з таким самим інтервалом |
| `wp_unschedule_event()` | `pre_unschedule_event` | Видаляє відповідний розклад Queuety |
| `wp_get_scheduled_event()` | `pre_get_scheduled_event` | Повертає дані розкладу з Queuety |

Перехоплюються лише **повторювані** події (ті, що мають властивість `schedule`, наприклад `hourly`, `twicedaily`, `daily`). Разові події, заплановані за допомогою `wp_schedule_single_event()`, не перехоплюються.

## Як відображаються події

Коли плагін викликає `wp_schedule_event()`, Queuety визначає назву розкладу через `wp_get_schedules()`, створює розклад Queuety з назвою обробника `__queuety_cron_{hook}` і зберігає назву початкового хука WordPress та аргументи в даних розкладу.

Передбачається, що воркер Queuety, який обробляє заплановане завдання, викликає `do_action()` з назвою початкового хука та аргументами, щоб наявні зворотні виклики WordPress виконувалися за розкладом, яким керує Queuety. `CronBridge::process_cron_event()` реалізує цей виклик, але поки ніщо його не запускає (див. обмеження вище). Розклади також перевіряються лише довготривалим процесом `wp queuety work` приблизно раз на хвилину (див. [Планування](https://queuety.inline0.dev/uk/docs/features/scheduling)).

### Визначення інтервалу

Спершу міст визначає назви розкладів через `wp_get_schedules()`, а потім використовує вбудовані значення за замовчуванням:

| Назва розкладу | Інтервал |
|---|---|
| `hourly` | 3,600 секунд |
| `twicedaily` | 43,200 секунд |
| `daily` | 86,400 секунд |
| `weekly` | 604,800 секунд |

Підтримуються власні інтервали розкладу, зареєстровані через фільтр `cron_schedules`, якщо `wp_get_schedules()` їх повертає.

## Відновлення WP-Cron

Щоб повернутися до стандартної системи WordPress cron:

```php
Queuety::restore_wp_cron();
```

Це видаляє хуки фільтрів і знову дає змогу WordPress обробляти події cron за допомогою вбудованого механізму. Зверніть увагу: під час установлення моста `DISABLE_WP_CRON` визначається як `true`, і під час роботи його не можна скасувати, тож, можливо, доведеться видалити цю константу з `wp-config.php` або перезапустити процес.

## Коли використовувати

Заміна найкорисніша для сайтів із низьким трафіком, коли потрібне надійніше планування, ніж може забезпечити WP-Cron, або коли ви вже використовуєте воркери Queuety і хочете, щоб виконання cron відбувалося в тій самій операційній системі. Вона також стане в пригоді, коли важлива централізована спостережуваність: події cron тоді відображатимуться в тих самих журналах і метриках, що й інша робота черг.

## Обмеження

Є кілька важливих обмежень. Потрібен активний воркер Queuety, інакше заплановані події ніколи не виконуватимуться. Перехоплюються лише повторювані розклади; разові події, створені за допомогою `wp_schedule_single_event()`, залишаються поза мостом. `replace_wp_cron()` також визначає `DISABLE_WP_CRON` на решту поточного процесу PHP, тож `restore_wp_cron()` видаляє хуки, але не може скасувати визначення константи. Нарешті, міст працює лише тоді, коли завантажено WordPress, оскільки він залежить від фільтрів WordPress і `do_action()`.

## Приклад: повне налаштування

```php
use Queuety\Queuety;

// In your plugin's main file.
add_action( 'plugins_loaded', function () {
    Queuety::replace_wp_cron();
} );
```

Тут не потрібно викликати `Queuety::init()`: активний плагін Queuety підключається до бази даних, використовуючи облікові дані WordPress, і ініціалізується під час `plugins_loaded`. `replace_wp_cron()` лише встановлює фільтри, тому не залежить від попередньої ініціалізації.

Після цього повторювані події, зареєстровані плагінами через `wp_schedule_event()`, зберігаються як розклади Queuety. Поки не буде виправлено [#9](https://github.com/inline0/queuety/issues/9), їхні зворотні виклики не виконуватимуться.