Заміна WP-Cron

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

Поточне обмеження: міст створює розклади Queuety, але у воркера немає обробника для завдань __queuety_cron_{hook}, які вони створюють, тому початкові зворотні виклики WordPress ніколи не виконуються. Кожне завдання завершується помилкою, повторюється зі збільшенням інтервалу й зрештою переміщується до відкладених (#9). Не вмикайте міст на сайті, де мають виконуватися події cron, доки це не буде виправлено.

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

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

use Queuety\Queuety;

Queuety::replace_wp_cron();

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

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

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

Перехоплюються лише повторювані події (ті, що мають властивість 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 приблизно раз на хвилину (див. Планування).

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

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

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

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

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

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().

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

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, їхні зворотні виклики не виконуватимуться.