WP-Cron: как работает и когда заменить на системный cron

Статья должна выйти в девять утра, а появляется только после первого посетителя. Импорт запускается с опозданием, служебные письма приходят пачкой, в магазине копятся фоновые действия. У этих симптомов бывают разные причины, но проверку WordPress стоит начать с WP-Cron — встроенного механизма выполнения задач по расписанию.

Разберём, как он работает, когда достаточно штатного запуска и как подключить системный cron без потери фоновых задач. Примеры ниже предназначены для WordPress; пути, домен и период запуска нужно адаптировать к своему хостингу. Настройки действующего сайта эта статья сама по себе не меняет.

Что такое WP-Cron и почему он зависит от посещений

WP-Cron хранит запланированные события WordPress и вызывает их обработчики, когда приходит время выполнения. Через него работают, например, проверка обновлений и публикация отложенных записей. Плагины могут добавлять собственные события: синхронизацию, очистку временных данных, отправку уведомлений.

По умолчанию это не постоянно работающий процесс. Загрузка страницы, при которой выполняется WordPress, даёт повод проверить расписание и инициировать обработку наступивших событий. Если событие назначено на 09:00, а следующий такой запрос пришёл в 09:17, запуск может задержаться до этого момента.

Посетитель и выполнение PHP — разные вещи. Если страницу целиком отдаёт внешний кеш, запрос может не дойти до WordPress. Поэтому число просмотров в аналитике не показывает, как часто система получает возможность запустить расписание. Задержка также может возникать из-за ошибок обработчика или проблем с запуском фонового запроса.

Регулярные события в WP-Cron задаются интервалом, а не полной строкой системного cron. Встроенные варианты включают ежечасный, дважды в сутки, ежедневный и еженедельный запуск. Время наступления события означает готовность к выполнению, но не обещает точного старта и завершения в эту секунду.

Когда переходить на системный запуск

Для небольшого сайта без чувствительных к задержке операций штатного механизма может быть достаточно. Оценивать стоит не сам факт использования WP-Cron, а наблюдаемый результат: вовремя ли публикуются записи, обновляются данные и обрабатываются фоновые действия.

Внешний планировщик полезен, если сайт посещают нерегулярно, страницы обслуживаются полным кешем или требуется предсказуемый интервал проверки. Для магазина и интеграций особенно важно заранее определить допустимую задержку. «Раз в час» подходит не всякому процессу, даже если нагрузка невелика.

При этом системный cron заменяет источник запуска, а расписание и обработчики остаются в WordPress. Он не ускорит медленный запрос к поставщику и не исправит PHP-ошибку плагина. Если одна задача исполняется десять минут, более частые обращения к планировщику сами по себе не сделают её быстрой.

Сначала проверьте, что именно задерживается

Начните со списка событий через WP-CLI — инструмент управления WordPress из командной строки. Если он ещё не настроен, пригодится шпаргалка команд на каждый день. Команды запускают на сервере от пользователя сайта, указав фактический путь установки:

wp --path=/var/www/example.com/public cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence

Здесь hook — имя события, next_run_gmt — время следующего запуска в GMT, next_run_relative — относительное время, recurrence — повторение. Сохраните вывод, а затем сравните его после очередного ожидаемого запуска. Не сопоставляйте время GMT с местными часами без пересчёта.

До перехода на внешний запуск можно проверить штатный механизм:

wp --path=/var/www/example.com/public cron test

Эта команда проверяет запуск WP-Cron, включая попытку HTTP-обращения к сайту. Успешная проверка не доказывает, что каждый обработчик завершил работу. После установки DISABLE_WP_CRON=true команда сообщит об отключённом механизме: это ожидаемо и не означает поломку правильно настроенного внешнего запуска.

Если список просроченных событий растёт, сопоставьте время задержки с журналами. В статье о логах WordPress разобрано, где искать сообщения. Для постоянного наблюдения полезнее мониторинг ошибок PHP на проде, чем периодическое открытие административной панели.

Вариант 1: вызывать wp-cron.php по HTTPS

Официальное руководство WordPress предлагает подключить системный планировщик к wp-cron.php. Это удобно и на хостинге с панелью задач: не всегда нужен собственный VPS. Сначала уточните, не настроен ли такой запуск самим хостером, чтобы не добавлять второй источник поверх существующего.

Для пользовательского crontab в Linux пример проверки каждые пять минут выглядит так:

*/5 * * * * /usr/bin/curl --fail --silent --show-error --max-time 240 --output /dev/null https://example.com/wp-cron.php

Замените адрес на конечный HTTPS-адрес своего сайта и проверьте путь к curl. В панели хостинга расписание обычно заполняется отдельно: туда вставляют только команду после пяти полей времени. Пример относится к пользовательскому crontab; у системных файлов cron может быть дополнительное поле пользователя.

У curl параметр --fail делает HTTP-ошибки причиной ненулевого кода завершения, --silent --show-error убирает индикатор прогресса, сохраняя сообщения об ошибках. Ответ не сохраняется благодаря --output /dev/null. Ограничение времени защищает от бесконечного ожидания ответа; его подбирают под конкретный процесс.

Не скрывайте ошибки перенаправлением всего вывода в пустоту. Настройте журнал или уведомления планировщика. Проверьте, что запрос не попадает на редирект, страницу входа или проверку браузера: успешная доставка обычной HTML-страницы ещё не означает запуск WordPress cron.

Вариант 2: запускать наступившие события через WP-CLI

При наличии доступа к серверу можно выполнять события напрямую через WP-CLI. Для ручной проверки используется:

wp --path=/var/www/example.com/public cron event run --due-now

Флаг --due-now выбирает события, срок которых уже наступил. Это рабочий запуск, а не просмотр: обработчики могут отправлять письма, менять данные и обращаться к внешним сервисам. Сначала изучите список задач и выберите подходящее время для проверки. Для регулярного исполнения ту же команду размещают в планировщике с абсолютным путём к исполняемому файлу WP-CLI.

Не подменяйте этот флаг на --all: тот запускает все события, в том числе ещё не наступившие. И не добавляйте --skip-plugins без понимания последствий: обработчик нужного события может находиться именно в плагине.

Проверьте команду от того же пользователя, под которым будет работать планировщик. У него должны быть права на файлы и доступ к базе. Уточните используемую версию PHP и расширения: окружение командной строки может отличаться от веб-сервера. Для multisite целевой сайт задают явно через --url; один запуск не стоит считать проверкой всей сети.

Как переключить запуск и проверить результат

1. Сохраните текущие настройки и список событий. Уточните, кто уже запускает cron: WordPress, панель хостинга или отдельная служба.
2. Настройте один выбранный внешний способ. Проверьте команду вручную и дождитесь реального запуска по расписанию.
3. После этого добавьте в wp-config.php перед загрузкой WordPress строку ниже. Если константа уже определена, измените существующую запись вместо добавления второй.
4. Проверьте несколько следующих циклов, журналы и конкретный результат нужной задачи.

define( 'DISABLE_WP_CRON', true );

Эта настройка отключает штатное инициирование cron при загрузке страниц. Нельзя ограничиться её добавлением: без работающего внешнего запуска задачи могут перестать исполняться. Для возврата к прежней схеме сначала восстановите штатный запуск, убрав настройку или изменив значение на false, затем удалите ненужную внешнюю задачу.

Пять минут — пример интервала, а не универсальная норма. Выбирайте его по допустимой задержке и длительности работы. Если обработка длится дольше интервала, выясните причину и схему защиты от пересечений; не создавайте несколько независимых запусков в надежде быстрее разобрать очередь.

WP-Cron и Action Scheduler: как они связаны

Action Scheduler — отдельная очередь фоновых действий, применяемая в WooCommerce и других плагинах. У неё есть журнал и статусы выполнения. Подробности разобраны в статье об асинхронных задачах WooCommerce.

В типовой схеме библиотека планирует событие action_scheduler_run_schedule через WP-Cron и использует дополнительные асинхронные обращения для обработки очереди. Поэтому зависимость от запуска расписания важна, но список событий WP-Cron не является списком всех действий магазина.

Если заказы обрабатываются с задержкой, проверьте и очередь Action Scheduler: ожидающие и неудачные действия, сообщения об ошибках, возраст самой старой задачи. Исправление источника запуска не исправляет ошибку конкретного действия. Массово удалять ожидающие действия ради красивого счётчика нельзя: среди них могут быть нужные операции.

Что считать успешной настройкой

Нужны три подтверждения: планировщик действительно срабатывает, WordPress выполняет наступившие события, а нужный бизнес-результат появляется без недопустимой задержки. Например, запись опубликована, импорт завершён, уведомление передано в отправку. Один ответ HTTP 200 подтверждает слишком мало.

Системный cron имеет смысл подключать ради предсказуемости запуска. Сохраните команду, пользователя, интервал и место журналов в документации проекта. Тогда при следующем сбое будет понятно, где заканчивается работа планировщика и начинается задача WordPress, которую нужно диагностировать отдельно.