В WordPress публикация запланированных записей, проверка обновлений плагинов и тем, резервное копирование и отложенные действия WooCommerce выполняются через встроенный механизм WP-Cron. Несмотря на название, это не настоящий планировщик сервера. WP-Cron проверяется только тогда, когда кто-то открывает страницу сайта: при каждом запросе WordPress смотрит, есть ли задачи, время которых пришло, и если есть — отправляет фоновый запрос к wp-cron.php. Такой подход придуман, чтобы всё работало на любом хостинге без настройки, но у него серьёзные недостатки.
Где WP-Cron подводит
Первая проблема возникает на сайтах с небольшой посещаемостью. Если ночью на сайт никто не заходит, новость, запланированная на 7:00, не выйдет, пока утром не появится первый посетитель. Иногда WordPress вообще пропускает запись и помечает её как «Missed schedule». Точно так же опаздывают резервные копии и рассылки подписчикам.
Вторая проблема, наоборот, касается популярных сайтов. Проверка выполняется при каждом открытии страницы, и если есть задачи к выполнению, wp-cron.php вызывается снова и снова. Это занимает воркеры PHP и замедляет сайт на пике трафика. Третий случай — полное кеширование страниц: если страницы отдаются из кеша, PHP вообще не запускается, и WP-Cron не проверяется.
Cron сервера решает все эти проблемы. Он не зависит от посещений, запускается точно по расписанию и работает как один процесс.
Шаг 1: отключить автоматический запуск WP-Cron
Откройте файл wp-config.php в корне сайта и добавьте строку ниже. Она должна стоять выше комментария «That's all, stop editing!», рядом с другими строками define, иначе WordPress может её не учесть.
define( 'DISABLE_WP_CRON', true );
Эта настройка не удаляет задачи. Она лишь говорит WordPress не вызывать wp-cron.php самостоятельно при открытии страниц. Список задач остаётся в базе, и теперь их будет запускать cron сервера. Поэтому не пропускайте следующий шаг: иначе запланированные записи и обновления перестанут выполняться совсем.
Шаг 2: добавить cron на сервере
Самый простой способ — запускать wp-cron.php напрямую через PHP CLI. Так запрос не проходит через веб-сервер и не занимает воркеры, предназначенные для посетителей. Для большинства сайтов достаточно запуска раз в 5 или 15 минут.
*/5 * * * * cd /var/www/user/data/www/misol.uz && /usr/bin/php wp-cron.php >> /var/www/user/data/logs/wp-cron.log 2>&1
Если на сервере установлен WP-CLI, лучше использовать его. Следующая команда выполняет только задачи, время которых пришло, и выводит результат текстом, что упрощает чтение лога:
*/5 * * * * cd /var/www/user/data/www/misol.uz && /usr/local/bin/wp cron event run --due-now >> /var/www/user/data/logs/wp-cron.log 2>&1
Точные пути к php и wp зависят от сервера — проверьте их в терминале командами which php и which wp. В cron нужно указывать путь к той же версии PHP, на которой работает сайт, иначе новые плагины могут выдать синтаксическую ошибку на старом PHP.
Какую частоту выбрать
Частоту определяют задачи вашего сайта. Для новостного сайта задержка запланированной записи на несколько минут не страшна, поэтому подойдут 5–10 минут. В магазине на WooCommerce через этот же механизм работает очередь Action Scheduler, и при большом числе заказов интервал можно сократить до 1–2 минут. Для сайта-визитки или редко обновляемого блога хватит и 15–30 минут. Чтобы долгие задачи не накладывались друг на друга, полезно добавить перед командой flock -n /tmp/wpcron.lock.
Шаг 3: проверить, что всё работает
После настройки посмотрите список задач через WP-CLI. Для каждой показывается время следующего запуска; если эти времена не застревают в прошлом и регулярно обновляются, cron сервера работает.
cd /var/www/user/data/www/misol.uz
wp cron event list --fields=hook,next_run_relative
wp cron test
Если WP-CLI нет, список задач в админке покажет плагин вроде «WP Crontrol». Через несколько часов загляните и в лог: в нём не должно быть ошибок PHP. Надёжная проверка — запланировать запись через 10 минут и убедиться, что она вышла вовремя.
Пример: сайт школы
Администрация частной школы в Самарканде заранее писала объявления и ставила их на 7:30 утра, потому что именно в это время родители получали ссылку через Telegram-канал. Ночью посещений почти не было, и объявления часто выходили после 8 часов, когда приходил первый посетитель, а некоторые оставались с пометкой «Missed schedule». После включения DISABLE_WP_CRON и добавления cron сервера раз в 5 минут объявления стали выходить с отклонением не более нескольких минут. Заодно и плагин резервного копирования начал срабатывать каждую ночь в точное время.
Частые ошибки
- Добавили
DISABLE_WP_CRON, но забыли добавить cron сервера — в итоге не выполняется ни одна задача. - В cron использован относительный путь или забыт
cd—wp-cron.phpне находит файлы WordPress. - Строка вписана ниже комментария «That's all, stop editing!» — настройка не действует.
- В мультисайт-сети cron добавлен только для основного сайта — для каждого сайта нужен отдельный вызов с
--url.
На хостинге sayt.uz задание cron добавляется в разделе «Планировщик» панели ISPmanager, вход в которую выполняется из кабинета sayt.uz. Если не удаётся найти путь к WP-CLI или нужной версии PHP, напишите тикет в техподдержку.