В WooCommerce письмо New order уходит не только после оплаты, но и при создании заказа в зависимости от сценария оформления, платёжного шлюза и статуса. На небольшом магазине это часто незаметно, а вот в проектах с предзаказами, ручной проверкой оплат, B2B-согласованием или частичной оплатой почта быстро превращается в шум.
Задача здесь не в том, чтобы отключить все уведомления, а в том, чтобы точечно убрать отправку письма о новом заказе для конкретных статусов: например, pending, on-hold или кастомного статуса. Ниже — рабочий способ через фильтр WooCommerce, без правки ядра и без лишних плагинов.
Когда это действительно нужно
Сценарий обычно один из трёх:
- заказ создаётся до оплаты, но менеджеру не нужно письмо на этом этапе;
- платёжный шлюз сначала ставит заказ в
on-hold, а письмо только мешает; - в магазине есть ручная модерация заказов, и уведомление нужно отправлять только после перехода в нужный статус.
Если отключить уведомление без привязки к статусу, можно потерять полезные письма о реальных заказах. Поэтому лучше управлять логикой на уровне фильтра, а не выключать уведомление целиком в настройках.
Диагностика: откуда именно уходит письмо
Перед правкой кода проверьте, какой статус получает заказ в момент создания. Это важно, потому что разные способы оплаты ведут себя по-разному.
- Откройте любой тестовый заказ в админке WooCommerce.
- Посмотрите текущий статус сразу после оформления.
- Сделайте тест с разными способами оплаты: банковская карта, перевод, наложенный платёж, офлайн-оплата.
- Если используете кастомный плагин статусов, проверьте его slug — именно он понадобится в коде.
Если письмо приходит, хотя заказ уже переводится в другой статус через несколько секунд, проблема обычно не в WooCommerce, а в том, что уведомление срабатывает раньше смены статуса. В таком случае фильтр по статусу — самый предсказуемый вариант.
Решение через фильтр woocommerce_email_enabled_new_order
WooCommerce позволяет отключать отправку конкретного письма через фильтр woocommerce_email_enabled_new_order. Он получает флаг включения письма и объект письма. Мы можем проверить статус заказа и вернуть false, если письмо не нужно.
Пример: не отправлять письмо для статусов pending и on-hold
add_filter( 'woocommerce_email_enabled_new_order', 'wpscan_disable_new_order_email_for_statuses', 10, 2 );
function wpscan_disable_new_order_email_for_statuses( $enabled, $order ) {
if ( ! $order instanceof WC_Order ) {
return $enabled;
}
$blocked_statuses = array( 'pending', 'on-hold' );
if ( in_array( $order->get_status(), $blocked_statuses, true ) ) {
return false;
}
return $enabled;
}Код можно добавить в мини-плагин или в functions.php дочерней темы. Для боевого сайта мини-плагин надёжнее: он не зависит от темы и не пропадёт после обновления.
Пример: отключать письмо только для одного кастомного статуса
add_filter( 'woocommerce_email_enabled_new_order', 'wpscan_disable_new_order_email_for_custom_status', 10, 2 );
function wpscan_disable_new_order_email_for_custom_status( $enabled, $order ) {
if ( ! $order instanceof WC_Order ) {
return $enabled;
}
if ( 'awaiting-review' === $order->get_status() ) {
return false;
}
return $enabled;
}Здесь важно, что в get_status() WooCommerce возвращает slug без префикса wc-. Если статус в админке выглядит как wc-awaiting-review, в коде нужно использовать awaiting-review.
Если нужно не отключать, а перенести отправку на другой статус
Иногда письмо о новом заказе нужно не убрать, а просто отправлять позже — например, только после ручной проверки или после подтверждения оплаты. Тогда лучше не бороться с уведомлением, а управлять переходом статуса заказа.
Ниже пример: если заказ создан в статусе pending, переводим его в processing после успешной оплаты. Это уже зависит от платёжного шлюза, но логика обычно строится именно так.
add_action( 'woocommerce_payment_complete', 'wpscan_move_order_to_processing_after_payment' );
function wpscan_move_order_to_processing_after_payment( $order_id ) {
$order = wc_get_order( $order_id );
if ( ! $order ) {
return;
}
if ( 'pending' === $order->get_status() ) {
$order->update_status( 'processing' );
}
}Этот подход не заменяет фильтр письма, но помогает выстроить предсказуемую логику уведомлений: письмо уходит только тогда, когда заказ действительно готов к обработке.
Сравнение подходов
| Подход | Когда подходит | Минусы |
|---|---|---|
Фильтр woocommerce_email_enabled_new_order | Нужно отключить письмо для конкретных статусов | Надо аккуратно проверить статусы и сценарии оплаты |
| Отключение письма в настройках WooCommerce | Письмо не нужно вообще | Слишком грубо, теряются полезные уведомления |
| Изменение логики статусов заказа | Нужно перенести уведомление на другой этап | Зависит от платёжного шлюза и бизнес-процесса |
Проверка результата после внедрения
После добавления кода не ограничивайтесь визуальной проверкой в админке. Нужно убедиться, что письмо реально не уходит.
- Сделайте тестовый заказ с нужным способом оплаты.
- Проверьте статус заказа в админке.
- Посмотрите почтовый ящик менеджера и журнал отправки, если он есть.
- Если используете SMTP-плагин, проверьте его лог отправки.
- Повторите тест для каждого статуса, который должен быть исключён.
Если письмо всё ещё приходит, проверьте, не отправляет ли его другой плагин или кастомный код. В WooCommerce уведомления могут дублироваться, если кто-то добавил собственный хук на смену статуса.
Частые ошибки и как их исправить
Проверяют статус с префиксом wc-
Это самая частая ошибка. В коде WooCommerce обычно работает со статусом без префикса. То есть вместо wc-pending нужно писать pending.
Добавляют код в активную тему
После обновления темы код исчезает. Для такой логики лучше использовать дочернюю тему или маленький плагин для сайта.
Отключают письмо слишком рано
Если статус меняется позже, чем срабатывает уведомление, фильтр по статусу может не помочь. Тогда нужно смотреть цепочку хуков платёжного шлюза и момент, когда заказ получает нужный статус.
Не проверяют кастомные статусы
Если у вас есть статус вроде awaiting-review, он не совпадёт с базовыми статусами WooCommerce. Сначала проверьте slug статуса, потом добавляйте его в массив блокировки.
Чек-лист перед выкладкой на боевой сайт
- проверен точный slug статуса заказа;
- код добавлен не в основную тему, а в устойчивое место;
- сделан тестовый заказ с каждым нужным способом оплаты;
- проверено, что письмо не уходит только для нужных статусов;
- нет дублирующего кода в другом плагине или в теме;
- если используется SMTP, проверен журнал отправки.
Практические советы по безопасности и поддержке
Если вы вносите такую логику на продакшене, не редактируйте файлы через встроенный редактор WordPress. Лучше залить код через Git, SFTP или подготовить отдельный мини-плагин. Так проще откатить изменение, если поведение оплаты или уведомлений изменится после обновления WooCommerce.
Ещё один полезный момент: если магазин активно растёт, держите рядом журнал почты. Это не только помогает поймать лишние письма, но и быстро отличить проблему WooCommerce от проблемы SMTP или хостинга.
Если вам нужно не только отключить письмо, но и убрать лишний шум в админке, иногда удобнее сочетать это с очисткой служебных дублей и мусорных данных. Для таких задач можно посмотреть Clearfy Pro, если он уже используется в проекте и подходит по стеку.