Как отключить отправку писем в WooCommerce при тестовом заказе

Тестовый заказ в WooCommerce часто нужен не ради «проверить, что всё вообще работает», а чтобы спокойно прогнать оплату, статусы, склад, интеграции с CRM и доставкой. Проблема в том, что вместе с тестом магазин может разослать реальные письма: клиенту, менеджеру, бухгалтерии, сервису уведомлений. Если это не отловить заранее, потом приходится вручную объяснять, почему из боевого магазина ушло «Спасибо за заказ» на тестовый email.

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

Когда это действительно проблема

Сценарий обычно выглядит так: вы создаёте заказ вручную, оформляете тестовую покупку через sandbox-оплату или прогоняете checkout на staging-копии сайта. WooCommerce при этом отрабатывает штатно и запускает уведомления на события заказа. Если сайт подключён к SMTP, сервису рассылок или CRM, письмо может уйти наружу почти мгновенно.

Особенно часто это всплывает в таких случаях:

• на тестовом сайте используется реальная почта администратора;
• клиентские письма настроены через сторонний SMTP-плагин;
• в магазине включены уведомления о новых заказах, возвратах и смене статуса;
• тестовый заказ создаётся не в отдельной среде, а на боевом сайте с реальными данными.

Диагностика: какие письма уходят и откуда

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

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

Что проверить перед изменениями

• какой адрес указан в WooCommerce > Настройки > Письма;
• используется ли SMTP-плагин и есть ли у него логирование;
• есть ли отдельные уведомления у плагинов доставки, оплаты или CRM;
• не включены ли вебхуки, которые реагируют на заказ независимо от писем WooCommerce.

Пошаговое решение: отключить письма только для тестового заказа

Самый предсказуемый вариант — добавить условие, которое отключает отправку писем только в тестовой среде или только для заказов с определённым признаком. Не стоит выключать уведомления глобально без фильтра: потом легко забыть вернуть всё назад.

Вариант 1. Отключать письма на staging-сайте

Если у вас отдельная тестовая копия сайта, используйте проверку окружения. В WordPress для этого удобно опираться на wp_get_environment_type(). Ниже пример, который полностью отключает отправку писем WooCommerce на staging и development.

add_filter( 'woocommerce_email_enabled', function( $enabled, $email ) {
    if ( function_exists( 'wp_get_environment_type' ) ) {
        $env = wp_get_environment_type();
        if ( in_array( $env, array( 'development', 'staging' ), true ) ) {
            return false;
        }
    }

    return $enabled;
}, 10, 2 );

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

Вариант 2. Отключать письма только для заказов с меткой

Если тестовый заказ создаётся вручную или через отдельный сценарий, можно пометить его метаданными и по этому признаку не отправлять письма. Пример ниже отключает письма, если у заказа есть мета-поле _test_order со значением yes.

add_filter( 'woocommerce_email_enabled', function( $enabled, $email ) {
    if ( ! is_a( $email, 'WC_Email' ) ) {
        return $enabled;
    }

    $order_id = 0;

    if ( isset( $_POST['order_id'] ) ) {
        $order_id = absint( $_POST['order_id'] );
    }

    if ( ! $order_id ) {
        return $enabled;
    }

    $test_flag = get_post_meta( $order_id, '_test_order', true );

    if ( 'yes' === $test_flag ) {
        return false;
    }

    return $enabled;
}, 10, 2 );

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

Вариант 3. Не отправлять письма на конкретный тестовый email

Если задача — не глушить уведомления целиком, а просто не слать их на тестовый адрес, можно отфильтровать получателя. Это полезно, когда вы хотите сохранить логику WooCommerce, но не засорять почту команды.

add_filter( 'woocommerce_email_recipient_new_order', function( $recipient, $order ) {
    if ( ! $order instanceof WC_Order ) {
        return $recipient;
    }

    $test_email = 'test@example.com';
    $emails = array_map( 'trim', explode( ',', $recipient ) );
    $emails = array_diff( $emails, array( $test_email ) );

    return implode( ',', $emails );
}, 10, 2 );

Это не отключает письмо полностью, но убирает конкретный адрес из списка получателей. Для небольших команд это часто самый безопасный компромисс.

Сравнение подходов

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

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

1. Сделайте тестовый заказ в нужной среде.
2. Проверьте, что письмо не пришло на адрес клиента и администратора.
3. Откройте логи SMTP-плагина, если он используется.
4. Убедитесь, что статус заказа в админке меняется как обычно.
5. Проверьте, не сломались ли другие уведомления, например письма о возврате или смене статуса.

Если письма всё равно уходят, значит уведомление генерирует не WooCommerce, а другой плагин или интеграция. В таком случае ищите отправку в логах SMTP и отключайте уже на уровне конкретного расширения.

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

Отключили все письма глобально

Так делают через слишком широкий фильтр, а потом забывают вернуть отправку. В результате магазин перестаёт слать важные уведомления о реальных заказах. Решение — ограничить условие окружением, меткой заказа или конкретным email.

Проверяют только письмо клиенту

В WooCommerce есть отдельные уведомления для администратора и для клиента. Иногда отключают только customer email, а письмо о новом заказе менеджеру всё равно уходит. Нужно смотреть на конкретный тип письма и его recipient-фильтр.

Тестируют на боевом сайте с реальной почтой

Это самый неприятный сценарий. Даже если заказ «ненастоящий», письмо может уйти реальному человеку. Для таких тестов лучше использовать staging или хотя бы временно подменять адреса получателей.

Забывают про сторонние интеграции

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

Практические советы по безопасности и производительности

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

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

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

function wpplugin_should_disable_wc_emails( $order_id ) {
    if ( ! $order_id ) {
        return false;
    }

    $flag = get_post_meta( $order_id, '_test_order', true );

    return 'yes' === $flag;
}

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