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

На тестовом сайте WordPress чаще всего проблема не в самом письме, а в том, что staging внезапно начинает слать реальные уведомления: новые заказы WooCommerce, письма из контактной формы, сброс пароля, уведомления администратора. Это быстро превращается в шум, а иногда и в риск, если тестовая база содержит настоящие адреса клиентов.

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

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

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

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

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

Перед изменениями полезно понять источник отправки. В WordPress письма обычно уходят через wp_mail(), а уже поверх него работают плагины форм, WooCommerce, уведомления ядра и сторонние интеграции. Если просто поставить «тихий» SMTP-плагин, часть писем может продолжить уходить через другие каналы.

Что проверить в первую очередь

• Есть ли на staging реальная почтовая конфигурация SMTP или транзакционный сервис.
• Не включены ли формы с отправкой на боевые адреса.
• Не импортирована ли в тестовую базу настоящая почта пользователей.
• Не настроены ли уведомления WooCommerce на реальные ящики.
• Не отправляет ли тема или кастомный код письма через wp_mail() напрямую.

Если на сайте уже стоит плагин логирования писем, сначала посмотрите журнал. Это помогает понять, какие письма генерируются, даже если вы ещё не отключили отправку. Но логирование само по себе проблему не решает.

Рабочие способы отключить почту на staging

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

Вариант 1: полностью глушим письма на staging

Если задача простая — на тестовом сайте письма не должны уходить вообще — используйте фильтр pre_wp_mail. Он позволяет перехватить отправку до того, как WordPress попытается доставить письмо.

<?php
/**
 * Plugin Name: Staging Mail Blocker
 * Description: Отключает отправку почты на staging.
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_filter( 'pre_wp_mail', function( $pre, $atts ) {
    if ( defined( 'WP_ENVIRONMENT_TYPE' ) && WP_ENVIRONMENT_TYPE === 'staging' ) {
        if ( ! defined( 'WP_DEBUG' ) || WP_DEBUG ) {
            error_log( 'Mail blocked on staging: ' . wp_json_encode( $atts ) );
        }

        return true; // сообщаем WordPress, что письмо «обработано»
    }

    return $pre;
}, 10, 2 );

Такой вариант удобен тем, что WordPress считает письмо отправленным, а реальной доставки не происходит. Для staging это обычно именно то, что нужно: формы и заказы не ломаются, но письма не уходят наружу.

Файл лучше положить в wp-content/mu-plugins/, чтобы он загружался всегда и не зависел от активации в админке.

Вариант 2: блокируем только часть писем

Иногда на staging нужно оставить системные письма для разработчиков, но отключить клиентские уведомления WooCommerce или письма из форм. Тогда фильтр можно сделать точечным и смотреть на получателя или тему письма.

<?php
add_filter( 'pre_wp_mail', function( $pre, $atts ) {
    if ( ! defined( 'WP_ENVIRONMENT_TYPE' ) || WP_ENVIRONMENT_TYPE !== 'staging' ) {
        return $pre;
    }

    $to = $atts['to'] ?? '';
    $subject = $atts['subject'] ?? '';

    $blocked_domains = array( 'customer@example.com', 'orders@site.tld' );

    foreach ( $blocked_domains as $blocked ) {
        if ( is_string( $to ) && str_contains( $to, $blocked ) ) {
            return true;
        }
    }

    if ( is_string( $subject ) && str_contains( mb_strtolower( $subject ), 'order' ) ) {
        return true;
    }

    return $pre;
}, 10, 2 );

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

Вариант 3: перенаправить письма в тестовый ящик

Если письма нужны для отладки, но не должны уходить клиентам, можно не отключать отправку полностью, а подменить адрес получателя. Для этого подходит фильтр wp_mail или phpmailer_init, но на практике проще и безопаснее использовать pre_wp_mail и отправлять копию в один внутренний ящик через свой код. Ниже — пример с заменой получателя.

<?php
add_filter( 'wp_mail', function( $args ) {
    if ( ! defined( 'WP_ENVIRONMENT_TYPE' ) || WP_ENVIRONMENT_TYPE !== 'staging' ) {
        return $args;
    }

    $args['to'] = 'staging-mailbox@example.com';
    $args['subject'] = '[STAGING] ' . $args['subject'];

    return $args;
} );

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

Пошаговая настройка без лишнего риска

1. Проверьте, что staging действительно помечен как staging через WP_ENVIRONMENT_TYPE в wp-config.php или через переменные окружения хостинга.
2. Создайте MU-plugin с блокировкой почты.
3. Добавьте логирование хотя бы на время проверки, чтобы видеть, какие письма пытались уйти.
4. Протестируйте форму, регистрацию и тестовый заказ WooCommerce.
5. Убедитесь, что письма не приходят на внешние адреса и не попадают в SMTP-очередь.

Если у вас есть доступ к серверу, полезно дополнительно проверить, не отправляет ли хостинг почту на уровне MTA. Иногда WordPress письма блокирует, но сторонний код или cron-задача всё равно шлёт уведомления через серверную почтовую систему.

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

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

• Отправьте тестовую форму с контактной страницы.
• Создайте новый заказ WooCommerce в тестовом режиме.
• Запросите сброс пароля для тестового пользователя.
• Проверьте журнал почты, если он включён.
• Посмотрите error_log или лог MU-plugin, если вы добавляли запись о блокировке.

Если письмо всё ещё уходит, значит, оно не проходит через wp_mail() или ваш фильтр подключён слишком поздно. В таком случае смотрите, не использует ли плагин собственный SMTP-клиент или внешний API.

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

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

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

Поставили блокировку в теме, а не в MU-plugin

Код в теме пропадает при смене темы или обновлении. Для staging-ограничений это плохое место. MU-plugin надёжнее, потому что загружается всегда и не зависит от интерфейса.

Не учли реальный SMTP

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

Забыли про cron и фоновые задачи

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

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

Отключение почты на staging — это не только про удобство. Это ещё и про защиту данных. Если в тестовой базе есть реальные адреса, лучше не допускать даже случайной отправки. Для таких сайтов полезно дополнительно:

• заменить реальные адреса пользователей на тестовые при синхронизации базы;
• ограничить доступ к staging по IP или basic auth;
• выключить индексацию и закрыть сайт от поисковиков;
• не хранить боевые SMTP-ключи в тестовом окружении;
• проверять, что webhooks и интеграции платежей тоже отключены или переведены в sandbox.

Если нужен не полный запрет, а аккуратная отладка писем, можно использовать отдельный тестовый почтовый ящик и журналирование. Для этого подойдут и сторонние плагины, и собственный код. Но на staging я бы всё равно начинал с жёсткого запрета, а уже потом включал точечную доставку для диагностики.

Если вы ведёте несколько сред — local, staging, production — удобно держать одинаковую логику через WP_ENVIRONMENT_TYPE. Тогда правило отправки почты будет зависеть не от ручной настройки в админке, а от самой среды, и это проще сопровождать в команде.