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

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

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

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

Сценарий обычно такой: вы развернули копию сайта для верстки, тестирования плагинов или проверки обновлений, а WordPress продолжает жить как боевой. В результате:

• уведомления о новых пользователях и сбросе пароля уходят на реальные адреса;
• WooCommerce отправляет письма о заказах, хотя это тестовые транзакции;
• плагины форм, подписок и CRM-интеграций пытаются дергать внешние SMTP/API;
• команда получает ложные события и начинает искать “почему письма не дошли”, хотя проблема в staging.

Если staging закрыт от индексации, это не решает вопрос с почтой. Отправка писем происходит на уровне PHP и плагинов, а не поисковых роботов.

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

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

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

• Есть ли на сайте SMTP-плагин и не настроен ли он на боевой почтовый сервер.
• Использует ли форма обратной связи wp_mail() напрямую или внешний API.
• Есть ли в wp-config.php константы, которые меняют поведение окружения.
• Не включены ли в WooCommerce боевые адреса получателей уведомлений.

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

Быстрая проверка на staging

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

Пошаговое решение: как отключить отправку почты

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

Вариант 1. Отключить отправку через SMTP-плагин

Если на staging стоит плагин вроде WP Mail SMTP или аналогичный, самый безопасный путь — не держать там боевые настройки. Уберите SMTP-учётные данные, отключите плагин или переключите его в режим логирования без реальной отправки, если такой режим предусмотрен самим плагином.

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

Вариант 2. Подменить получателя на тестовый адрес

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

<?php
add_filter( 'wp_mail', function( $args ) {
    if ( defined( 'WP_ENVIRONMENT_TYPE' ) && WP_ENVIRONMENT_TYPE === 'staging' ) {
        $args['to'] = 'staging-mailbox@example.com';
    }

    return $args;
} );

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

Вариант 3. Полностью заблокировать wp_mail() на staging

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

<?php
add_filter( 'pre_wp_mail', function( $pre, $atts ) {
    if ( defined( 'WP_ENVIRONMENT_TYPE' ) && WP_ENVIRONMENT_TYPE === 'staging' ) {
        if ( function_exists( 'error_log' ) ) {
            error_log( 'Blocked wp_mail on staging: ' . wp_json_encode( $atts ) );
        }

        return true; // сообщаем WordPress, что отправка обработана
    }

    return $pre;
}, 10, 2 );

Здесь важный момент: мы не ломаем вызов, а говорим WordPress, что письмо уже “обработано”. Это снижает риск фатальных ошибок в плагинах, которые ожидают успешный результат.

Если нужен только запрет для WooCommerce

Иногда на staging нужно оставить письма от форм, но отключить уведомления магазина. В WooCommerce это лучше делать через настройки уведомлений, а не через глобальную блокировку. В админке откройте WooCommerce → Настройки → Email и отключите нужные типы уведомлений для тестовой среды.

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

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

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

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

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

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

Оставили боевой SMTP на staging

Это самая частая причина утечек. Даже если вы блокируете wp_mail(), внешний плагин может отправлять письма напрямую через API. Решение простое: на staging отключить боевые ключи и проверить настройки доставки отдельно.

Заблокировали только ядро WordPress, но не плагины

Некоторые плагины не используют стандартную отправку или делают это через собственные механизмы. В таком случае фильтр pre_wp_mail не поможет против внешнего API. Нужно смотреть документацию конкретного плагина и отключать отправку в его настройках.

Сломали тестовые уведомления, которые были нужны

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

Забыли про cron-задачи

Планировщик WordPress может запускать письма по расписанию: напоминания, отчёты, уведомления о подписках. После отключения почты проверьте, не завязаны ли эти задачи на отправку писем. Иначе вы получите тихие ошибки в фоне.

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

На staging лучше явно маркировать окружение. В wp-config.php можно задать:

<?php
define( 'WP_ENVIRONMENT_TYPE', 'staging' );

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

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

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

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

Что делать, если письма всё равно уходят

Если после всех правок письма продолжают приходить, почти наверняка источник не в стандартном wp_mail(). Тогда проверьте:

• внешние формы с собственной отправкой через API;
• SMTP-плагин и его журнал отправки;
• плагины подписок, бронирований и уведомлений;
• кастомный код в теме или mu-plugin;
• серверные cron-задачи, которые запускают отдельные скрипты.

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