Сайт, чья статья, запланированная на девять утра, публикуется только к середине утра, или чьё ночное резервное копирование, кажется, срабатывает через ночь, обычно страдает от распространённого заблуждения о работе WordPress: система, призванная выполнять эти запланированные задачи, называемая WP-Cron, не является настоящим планировщиком в том смысле, в каком его понимает сервер.
Что WP-Cron делает на самом деле
Настоящий cron на уровне системы — это механизм сервера, срабатывающий в фиксированное время независимо от какой-либо внешней активности, точно как часы. WP-Cron, напротив, срабатывает только тогда, когда посетитель загружает страницу сайта. При каждой загрузке страницы WordPress проверяет, не наступил ли срок какой-либо запланированной задачи, и если да, выполняет её именно в этот момент, а не в назначенное время. Такая архитектура, изначально выбранная для работы на любом хостинге без специфической настройки сервера, работает достаточно хорошо, пока сайт получает регулярный поток посещений.
Проблема на сайте с низким трафиком
Сайт-визитка или блог, который посещают лишь несколько человек в день, может оставаться без единого посещения несколько часов подряд, особенно ночью. Если задача запланирована на три часа ночи, а ни один посетитель не загружает страницу до восьми утра, эта задача просто не выполняется до этого момента. Статья, запланированная на раннее утро, поэтому публикуется с опозданием, ночное резервное копирование сдвигается соответственно, а запланированное письмо отправляется намного позже, чем предполагалось, без каких-либо видимых ошибок в админ-панели сайта.
Обратная проблема на сайте с высоким трафиком
На сайте со значительным трафиком WP-Cron срабатывает при каждой загрузке страницы, что может означать выполнение проверки десятки или сотни раз в минуту. Эта повторяющаяся проверка без необходимости расходует ресурсы сервера и может способствовать общему замедлению работы, которое трудно диагностировать, поскольку её эффект сливается с другими процессами сайта, а не выделяется как отдельная причина.
Рекомендуемое решение: настоящий системный cron
Стандартное решение — отключить поведение WP-Cron по умолчанию, добавив строку define открывающая скобка кавычка DISABLE_WP_CRON кавычка запятая true закрывающая скобка точка с запятой в файл wp-config.php, а затем настроить настоящий cron на уровне сервера, обычно доступный через панель управления хостингом или командную строку. Этот системный cron вызывает файл wp-cron.php сайта через регулярные интервалы, часто каждые пять минут, гарантируя надёжное выполнение запланированных задач независимо от реального трафика сайта. Большинство хостинг-провайдеров, ориентированных на WordPress, предлагают такую настройку в несколько кликов из своего интерфейса управления.
Диагностика неработающей запланированной задачи
Прежде чем менять конфигурацию, полезно точно проверить, какие задачи запланированы и на какое время, что позволяет сделать плагин вроде WP Crontrol, показывающий полный список запланированных событий, позволяющий запускать их вручную для теста и помогающий обнаружить зависшую или дублирующуюся задачу — частую проблему, когда несколько плагинов планируют похожие проверки без согласования друг с другом.
Случай тяжёлых, повторяющихся задач
Для более сложной обработки, чем простая отложенная публикация, например регулярная синхронизация данных с CRM или автоматическая отправка напоминаний клиентам, библиотека вроде Action Scheduler, нативно встроенная в WooCommerce, но пригодная и для отдельного использования, управляет постоянной очередью на основе базы данных с точным отслеживанием статуса каждой задачи. Такой подход лучше подходит для индивидуальной разработки на PHP или бизнес-автоматизации, требующей повышенной надёжности, чем простой хук WP-Cron.
Что стоит проверить перед публикацией: подтвердить, что рекомендуемый синтаксис отключения WP-Cron в wp-config.php остаётся неизменным для текущих версий WordPress, и проверить, что упомянутый плагин WP Crontrol остаётся активно поддерживаемым и доступным в официальном каталоге на момент публикации.