Как отключить отправку писем WooCommerce для отдельных статусов заказа

В WooCommerce письма часто начинают мешать не тогда, когда магазин растёт, а когда в процессах появляется лишняя автоматизация: уведомления о каждом переходе статуса, дубли на внутреннюю почту, письма клиенту на промежуточных этапах. В итоге менеджеры получают шум, а покупатели — сообщения, которые не добавляют пользы.

Ниже разберём, как точечно отключить отправку писем для конкретных статусов заказа, не ломая остальные уведомления. Это полезно, если нужно убрать, например, письма при переходе в on-hold или processing, но оставить уведомления об оплате и завершении заказа.

Когда это действительно нужно

Типичный сценарий: заказ создаётся, потом несколько раз меняет статус из-за оплаты, ручной проверки или синхронизации с CRM. WooCommerce по умолчанию может отправлять несколько писем подряд, и часть из них оказывается лишней. Особенно это заметно в магазинах с ручной модерацией, предзаказами, оплатой по счёту и частичной отгрузкой.

Если письма отключать полностью, можно потерять важные уведомления. Поэтому задача обычно не в том, чтобы «выключить всё», а в том, чтобы убрать только конкретные триггеры.

Диагностика проблемы

Перед правкой кода проверьте, какие именно письма отправляются и на каком этапе. В WooCommerce это можно увидеть в настройках WooCommerce → Настройки → Email. Там перечислены стандартные уведомления: клиентские и административные.

Полезно сначала ответить на три вопроса:

  • какой статус заказа вызывает лишнее письмо;
  • кому оно уходит: клиенту, администратору или менеджеру;
  • это стандартное письмо WooCommerce или его добавил плагин.

Если письмо приходит не из WooCommerce, а из CRM, службы доставки или маркетингового плагина, код ниже его не отключит. В таком случае нужно искать настройку именно в этом расширении.

Как отключить письма для конкретного статуса заказа

Самый надёжный способ — снять отправку через фильтр woocommerce_email_enabled_{id}. Он позволяет отключить конкретный тип письма, не затрагивая остальные уведомления.

Например, если нужно отключить письмо клиенту о новом заказе при определённом статусе, можно использовать такой код в functions.php дочерней темы или в собственном мини-плагине:

add_filter( 'woocommerce_email_enabled_customer_processing_order', 'wpweb_disable_processing_email_for_specific_status', 10, 2 );
function wpweb_disable_processing_email_for_specific_status( $enabled, $order ) {
    if ( ! $order instanceof WC_Order ) {
        return $enabled;
    }

    // Отключаем письмо, если заказ уже переведён в on-hold вручную.
    if ( $order->has_status( 'on-hold' ) ) {
        return false;
    }

    return $enabled;
}

Этот пример показывает принцип: вы проверяете статус заказа и возвращаете false, если письмо не нужно. Но на практике удобнее отключать не по текущему статусу заказа, а по самому типу письма, которое вы хотите убрать.

Отключение письма по ID уведомления

У WooCommerce у каждого письма есть свой ID. Например, customer_processing_order, customer_completed_order, new_order. Для каждого можно повесить отдельный фильтр.

add_filter( 'woocommerce_email_enabled_customer_completed_order', 'wpweb_disable_completed_email_for_admin_orders', 10, 2 );
function wpweb_disable_completed_email_for_admin_orders( $enabled, $order ) {
    if ( ! $order instanceof WC_Order ) {
        return $enabled;
    }

    // Пример: не отправлять письмо о завершении заказа для самовывоза.
    if ( $order->get_shipping_method() === 'Local pickup' ) {
        return false;
    }

    return $enabled;
}

Такой подход удобен, когда правило зависит не только от статуса, но и от способа доставки, способа оплаты или роли получателя.

Если нужно отключить письма только для части заказов

Иногда письмо нужно убрать не глобально, а только для заказов с определёнными признаками: сумма ниже порога, конкретный метод доставки, виртуальный товар, самовывоз, тестовые заказы. В этом случае лучше проверять свойства заказа, а не редактировать шаблоны писем.

Ниже пример, который отключает письмо менеджеру о новом заказе, если заказ создан с методом оплаты bacs и не требует немедленной обработки:

add_filter( 'woocommerce_email_enabled_new_order', 'wpweb_disable_new_order_email_for_bacs', 10, 2 );
function wpweb_disable_new_order_email_for_bacs( $enabled, $order ) {
    if ( ! $order instanceof WC_Order ) {
        return $enabled;
    }

    if ( $order->get_payment_method() === 'bacs' ) {
        return false;
    }

    return $enabled;
}

Если правило сложнее, лучше вынести его в отдельную функцию, чтобы не плодить дубли в нескольких фильтрах.

Сравнение подходов: плагин, код или настройка

ПодходКогда подходитПлюсыМинусы
Настройки WooCommerceНужно отключить стандартное письмо целикомБез кода, быстроНет точечной логики по статусам и условиям
Код через фильтрыНужно отключить письмо только для части заказовТочно, предсказуемо, без лишних плагиновНужна аккуратная проверка и тестирование
Плагин для email-уведомленийНужны сложные сценарии и интерфейс для менеджераУдобно для неразработчиковДополнительная нагрузка и риск конфликтов

Если у вас уже стоит плагин для оптимизации WooCommerce, например Clearfy Pro, проверьте, нет ли там отдельной настройки для отключения стандартных уведомлений. Но если задача точечная, код обычно надёжнее и прозрачнее.

Как проверить, что решение сработало

После внедрения не ограничивайтесь визуальной проверкой в админке. Нужно пройти реальный сценарий заказа.

  • Создайте тестовый заказ с нужным методом оплаты и доставки.
  • Переведите его в статус, который должен отключать письмо.
  • Проверьте, пришло ли письмо клиенту и/или администратору.
  • Сравните поведение с заказом, который не попадает под условие.

Если используете SMTP-плагин или почтовый лог, откройте журнал отправки и убедитесь, что письмо не было сформировано. Это важнее, чем просто отсутствие письма в ящике: иногда оно уходит, но задерживается или фильтруется почтовым сервисом.

Частые ошибки и как их исправить

Фильтр повесили не на тот ID письма

Это самая частая причина. Если вы отключаете не тот email ID, код просто не сработает. Сверяйте ID с документацией WooCommerce или с названием класса письма в коде плагина.

Проверяете статус заказа слишком рано

Если статус меняется асинхронно, в момент отправки письма он может быть ещё старым. Тогда условие не совпадёт. В таких случаях лучше проверять не только статус, но и метаданные заказа, способ оплаты или shipping method.

Редактируете шаблон письма вместо логики отправки

Удаление текста из шаблона не отключает отправку. Письмо всё равно будет создаваться и уходить. Если задача именно в отключении, нужен фильтр или настройка плагина.

Код добавили в активную тему

После обновления темы изменения могут пропасть. Для такой логики безопаснее использовать дочернюю тему или небольшой собственный плагин.

Безопасность и производительность

Отключение лишних писем само по себе полезно: меньше фоновых действий, меньше обращений к почтовому сервису, меньше шума в логах. Но не стоит делать это «в лоб» через глобальное отключение всех уведомлений, если магазин зависит от статусов заказа.

Если код пишете вручную, держите его в отдельном файле и не смешивайте с правками шаблонов. Для production-сайта лучше сначала прогнать сценарий на staging-копии, особенно если у вас подключены сторонние плагины оплаты и доставки.

Когда нужно управлять уведомлениями без кода и с понятным интерфейсом, можно посмотреть в сторону специализированных решений для WooCommerce-автоматизации. Но перед установкой любого плагина проверьте, не дублирует ли он уже существующую логику отправки писем.

Практический чек-лист перед публикацией изменений

  • Определён конкретный email ID, который нужно отключить.
  • Проверено, зависит ли условие от статуса, оплаты или доставки.
  • Код вынесен в дочернюю тему или мини-плагин.
  • Протестирован заказ с нужным сценарием.
  • Проверен почтовый лог или SMTP-лог.
  • Убедились, что остальные письма продолжают отправляться.

Если задача сводится к одному-двум сценариям, код через фильтры обычно даёт самый чистый результат: без лишних настроек, без тяжёлых расширений и без побочных эффектов для остальных уведомлений.

Как использовать WPRemark для автоматического модераирования комментариев в WordPress
25.12.2025
Как запретить индексацию внутренних поисковых страниц в WordPress
30.08.2026
Как удалить неиспользуемые термины таксономии в WordPress для оптимизации базы данных
11.01.2026
Как отключить REST API WordPress без потери функциональности
12.12.2025
Как избежать проблем с неработающими шорткодами в WordPress
26.04.2026