В магазине накопились ожидающие действия, обмен данными запаздывает, а отдельные операции заканчиваются ошибкой. Надпись «Ожидает» сама по себе ещё не доказывает сбой: действие могло быть назначено на будущее. Начните с просроченных задач и их журналов, чтобы отличить остановившуюся очередь от ошибки одного расширения.
Это руководство помогает собрать диагностику WooCommerce до массового запуска или удаления заданий. Цель — понять, какие операции задерживаются, кто их создаёт и по каким признакам можно подтвердить восстановление работы.
1. Найдите именно просроченные действия
Откройте «WooCommerce → Статус → Запланированные действия». Названия пунктов могут отличаться в переводе. В официальной документации WooCommerce описаны просмотр статусов, поиск по имени хука и группе, а также журналы ошибочных действий.
Сравните назначенное время с текущим временем сайта. Будущие задания в состоянии ожидания нормальны. Для первичной записи выберите старое просроченное действие и одно недавнее действие того же типа. Если задача повторяется, сравнивайте конкретные идентификаторы: новое ожидающее действие может появиться сразу после успешного предыдущего.
- Идентификатор действия и точное имя хука.
- Группа, статус и назначенное время.
- Последние строки журнала и время попытки.
- Наблюдаемый эффект: например, не передано определённое обновление.
2. Разделите остановку очереди и ошибку обработчика
Смотрите не только на общее число заданий. Сделайте два снимка списка через согласованный интервал наблюдения, например десять минут. Это пример для сравнения, а не норматив обработки. Запишите, какие конкретные действия завершились и какие остались без движения.
| Наблюдение | Следующая проверка |
|---|---|
| Ожидание назначено на завтра | Проверьте расписание; не запускайте раньше только ради пустого списка. |
| Просрочены действия разных групп, новых завершений нет | Проверьте запуск фонового обработчика и ограничения сервера. |
| Другие группы выполняются, одна постоянно ошибается | Соберите журнал и выясните владельца конкретного хука. |
| Действия завершаются, но очередь растёт | Сравните скорость появления и обработки; проверьте нагрузку и источник заданий. |
Это диагностические ориентиры, а не готовый диагноз. Одинаковый внешний симптом может иметь разные причины. Сообщение об ошибке полезнее предположения «сломался весь WooCommerce».
3. Установите, какое расширение отвечает за действие
Скопируйте имя хука целиком и найдите его в документации установленного расширения или передайте разработчику. Префикс даёт подсказку, но не является достаточным доказательством. Запишите версии WooCommerce, WordPress и предполагаемого компонента, а также дату последних изменений.
Сопоставьте начало задержек с обновлением, переносом или изменением доступа к внешнему сервису. Для этого пригодится журнал изменений WordPress. Совпадение по времени помогает выбрать проверку, но само по себе не подтверждает причинную связь.
4. Проверьте механизм запуска и серверные ошибки
WP-Cron проверяет наступившие события при загрузках страниц и не работает непрерывно. На малопосещаемом сайте это может задерживать запуск. Механизм описан в справочнике WordPress по WP-Cron. Action Scheduler использует его для запуска очереди, но конкретную конфигурацию магазина нужно проверять отдельно.
Попросите администратора проверить ошибки самозапросов, ограничения времени PHP, нехватку памяти и события защиты в тот же момент, когда задание пыталось выполниться. После переноса используйте также проверки WordPress на новом хостинге. Не увеличивайте лимиты вслепую: сначала нужен текст ошибки и время события.
Если в конфигурации установлено DISABLE_WP_CRON, выясните, настроен ли реальный внешний запуск и есть ли записи его выполнения. WordPress публикует порядок подключения системного планировщика. Отключать стандартный механизм следует после настройки и проверки замены. Интервал выбирают под задачи и ограничения хостинга; универсальной команды для любого сервера нет.
5. Подготовьте безопасную повторную попытку
Не запускайте все задания подряд. Сначала определите, что делает выбранное действие и может ли повтор вызвать второе письмо, повторный обмен или другую нежелательную операцию. Для задач, связанных с платежами и заказами, способ повтора нужно согласовать с разработчиком соответствующего расширения.
Сохраните журнал до вмешательства. Подготовьте проверенную резервную копию перед изменениями конфигурации или кода. Затем на тестовой копии воспроизведите ошибку, устраните предполагаемую причину и повторите одну понятную операцию. Не удаляйте таблицы планировщика и не отменяйте всю очередь как способ «очистить ошибки»: это лишает диагностику данных и может убрать нужную работу.
6. Подтвердите результат на двух уровнях
Успех в списке действий и успех бизнес-операции проверяются отдельно. Для обмена данными найдите контрольную запись в принимающей системе. Для уведомления проверьте получение, а не только завершение обработчика. Для повторяющегося задания дождитесь следующего штатного запуска без ручного вмешательства.
Что передать специалисту
Пример формулировки: «Действие №123, хук …, должно было выполниться в 09:00 по времени сайта. В 09:20 остаётся просроченным. Другие группы за это время завершились. В журнале: … . После обновления компонента … появились первые ошибки. Контрольная операция: …».
Чек-лист завершения
- Будущие действия отделены от просроченных.
- Сохранены идентификатор, хук, время и журнал проблемного задания.
- Определён ответственный компонент и проверен механизм запуска.
- Повторная попытка не создала дублирующих операций.
- Подтверждены фактический результат и следующий штатный запуск.
- Изменения и оставшиеся вопросы записаны для дальнейшего обслуживания.
Полезные товары по теме
Программа «Реестр установленных плагинов»
Вспомогательная программа для ведения списка компонентов сайта. Пригодится, чтобы собрать сведения о расширениях перед диагностикой и передать их специалисту. Карточка описывает ввод и сохранение данных; автоматическое определение владельца хука и исправление очереди не заявлены.