Как подтвердить работу WP-Cron и системного расписания: паспорт событий, контекст PHP и пользователя, контрольный результат, отсутствие дублей и наблюдение после переноса.
Почему расписание нельзя оценивать по посещению главной
WP-Cron обслуживает запланированные события WordPress и в обычной схеме зависит от вызовов, связанных с запросами сайта. Он не является постоянно работающим системным демоном. При этом задержка публикации или синхронизации может быть связана и с самим обработчиком. Нужно отдельно подтвердить, что наступил срок, произошёл запуск и завершилась полезная операция.
Статическая страница из внешнего кэша не обязательно запускает WordPress на origin. Поэтому посещение закэшированной главной нельзя считать надёжным тестом событий. С другой стороны, добавление системного cron не исправит ошибку авторизации API внутри задачи. До изменения составьте карту текущего запуска и зависимостей, чтобы не создать второй неконтролируемый механизм.
Определите зависимые задачи
Составьте список публикаций по расписанию, копий, синхронизаций и очередей. Для каждой укажите владельца плагина, интервал и допустимую задержку. Не удаляйте незнакомые события только из-за большого количества: они могут обслуживать магазин или интеграцию.
Сравните запланированное и фактическое время. Если сайт редко посещают, событие может запускаться позже ожидаемого. Но задержка также связана с ошибкой задачи, блокировкой или внешним запросом; не приписывайте всё отсутствию трафика.
Проверьте текущий механизм
Уточните константы WordPress, серверное расписание и рекомендации хостинга. Не добавляйте второй независимый запуск без понимания действующего. Слишком частые параллельные вызовы способны создавать лишнюю работу, если сама задача не защищена от повторов.
На VPS проверьте, от какого пользователя и какой версией PHP выполняется команда. Веб и консоль могут использовать разные расширения и настройки. На shared используйте поддерживаемый панелью способ и фактический путь проекта.
Как прочитать список событий без массового запуска
Если WP-CLI доступен и разрешён, начните с команды просмотра в каталоге нужной установки. Сверьте справку установленной версии и рабочий контекст. WP-CLI загружает приложение, поэтому учтите особенности подключённых плагинов. Команда чтения списка не означает выполнение всех событий, но параметры run и delete имеют уже другой смысл и не должны добавляться по аналогии.
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrenceВ отчёте сохраните hook, время и повторяемость, а владельца найдите по документации или коду компонента. Неизвестное имя не является доказательством вредоносности. Некоторые задачи одноразовые, другие периодические; аргументы могут различать разные события с одним hook. Не удаляйте «дубли» по одному имени, не разобрав назначение и аргументы.
| Поле паспорта | Практический смысл |
|---|---|
| Hook и владелец | Какой компонент выполняет работу |
| Срок и часовой пояс | Когда событие должно стать готовым |
| Источник запуска | Веб, панель, системный cron или другая схема |
| Контекст | Каталог, пользователь, PHP, окружение |
| Ожидаемый результат | Что должно измениться после обработки |
| Ошибка и повтор | Как увидеть сбой и безопасно продолжить |
Порядок перехода
| Шаг | Проверка |
|---|---|
| Снимок состояния | Сохранены настройки и список задач |
| Тест альтернативного запуска | Контрольное событие реально выполнено |
| Журнал | Ошибки видит ответственный |
| Согласованное переключение | Старый запуск отключён только после проверки нового |
| Наблюдение | Следующие штатные события выполняются вовремя |
Как тестировать
Используйте безопасное контрольное событие или действие, не создающее реальных заказов и писем клиентам. Проверьте статус и конечный результат. Сообщение «команда запущена» не означает, что функция завершилась без ошибки.
На стенде воспроизведите отсутствие трафика и проверьте расписание. Для каждой критичной задачи оцените поведение после пропуска: повторяется ли она, догоняет ли очередь, возможны ли дубликаты. Эти свойства зависят от приложения, а не только от cron.
Проверьте контекст системного задания
Системный запуск может использовать другое окружение, чем интерактивная SSH-сессия: иной PATH, рабочий каталог, версию PHP и переменные. Поэтому команда, работающая вручную, способна не работать из расписания. Запишите абсолютные подтверждённые пути и пользователя по документации площадки. Не используйте root только потому, что так исчезла ошибка прав: созданные файлы могут затем стать недоступны веб-процессу.
Секреты не следует встраивать в публичный URL или строку, попадающую в журнал и историю. Для системного запуска используйте поддерживаемый площадкой способ и защищённую конфигурацию. На shared панель может предоставлять готовый механизм; на VPS его планирует администратор. Проверка изменения включает фактический результат, код завершения и журнал, а не сообщение «задание добавлено».
Не отключайте старый механизм до готовности нового
Константа, отключающая автоматический вызов WP-Cron, сама по себе не создаёт системное расписание. Если сначала отключить старое и забыть проверить новое, события останутся без запуска. Выполните контролируемую проверку альтернативного способа, затем согласованное переключение с учётом защиты от одновременного выполнения.
Диагностика неработающей задачи
Если вызов планировщика успешен, а событие падает, исследуйте журнал PHP и владельца hook. Если сам запуск не выполняется, проверьте путь, пользователя, права, версию PHP и доступность требуемого адреса. Не меняйте все параметры сразу.
У задачи с внешним API проверьте ключи, лимиты и таймауты. Секреты не должны попадать в открытые журналы или командные примеры. Если код запускается слишком долго, рассматривайте партии и очередь с наблюдаемым прогрессом.
Учебный сценарий контроля без реальных клиентских действий
На изолированном стенде выберите безопасное известное событие или предусмотренную разработчиком тестовую задачу, которая пишет обезличенный маркер в закрытый журнал. Сохраните плановое время и ожидаемый результат. Проверьте выполнение при отсутствии пользовательских посещений, если цель — независимость от трафика. Это должен быть реальный запуск штатного расписания, а не ручное выполнение в конце теста.
- Подтвердите владельца и безвредность контрольного события.
- Запишите срок и ожидаемый маркер.
- Проверьте запуск выбранным механизмом в нужном окружении.
- Сверьте фактическое время и результат.
- Проверьте следующий штатный цикл и отсутствие повторного эффекта.
- Удалите только своё согласованное тестовое событие штатным способом после завершения проверки.
Не используйте отправку реальных заказов, списания и массовые письма как маркер. Для таких задач нужны песочница и отдельная приёмка. Учебный протокол не означает, что HOSTIO выполнял эти проверки на инфраструктуре провайдеров. В опубликованном отчёте должны оставаться только фактически полученные результаты.
Что контролировать постоянно
Наблюдайте возраст последнего успешного выполнения и число повторных ошибок. Пустой журнал может означать отсутствие запуска, а не безошибочную работу. Назначьте ответственного за уведомление и согласуйте срок хранения диагностических данных.
После переноса сайта обновите пути и проверьте, что старый сервер не продолжает выполнять те же задания. Два активных расписания способны дублировать письма и синхронизации. Отключение старого выполняется после подтверждения нового.
Перенос сайта и план возврата
После миграции особенно важно исключить два действующих расписания на старой и новой площадке. Одинаковая копия базы может содержать одинаковые события, а старый сервер продолжать отправлять уведомления или менять внешний каталог. До завершения переноса составьте перечень всех источников запуска, включая панель, системный cron и отдельные скрипты.
Порядок отключения старого и включения нового зависит от защиты обработчиков от повторов и допустимой паузы. Согласуйте его заранее. При возврате также проверьте, какая площадка сейчас уполномочена выполнять задачи. Возврат DNS не выключает системный cron автоматически. Для данных и внешних эффектов сохраните отдельную сверку — настройка расписания не отменяет уже выполненные операции.
FAQ и итог настройки
Если wp-cron.php открылся без ошибки, все события выполнены?
Нет. Нужно проверить конкретное событие, его журнал и конечный результат.
Можно ли добавить частый системный запуск, оставив всё как было?
Сначала выясните текущую схему и защиту от наложения. Избыточные параллельные вызовы могут создавать лишнюю работу и повторные эффекты.
Почему задача работает из SSH, но не из cron?
Сравните пользователя, каталог, пути PHP, расширения, переменные и права. Интерактивная оболочка и расписание могут отличаться.
Перенос домена останавливает старые задания?
Нет. Системное расписание старого сервера может продолжать работать независимо от DNS.
Сохраните паспорт критичных событий, проверенные циклы, ответственных за ошибки и план переключения. Расписание принято по выполненным задачам с правильными данными, а не по наличию строки в панели.
Источники и дата
Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.
