# Замена 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/ru/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), их обратные вызовы не выполняются.