# Заместител на 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/bg/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) не бъде отстранен, обратните им извиквания няма да се изпълняват.