На живом сайте WordPress письма часто начинают мешать быстрее, чем кажется: уведомления о новых пользователях, письма о сбросе пароля, системные сообщения плагинов, лишние письма WooCommerce на тестовой среде. Полностью отключать почту обычно не нужно — задача в том, чтобы убрать шум и оставить только то, что реально должно доходить до администратора, клиента или редактора.
Ниже разберём рабочий сценарий: как диагностировать источник писем, как отключить отправку точечно через код, как проверить результат и где чаще всего ошибаются.
Когда это действительно нужно
Чаще всего проблема выглядит так: на почту валятся уведомления, которые никто не использует, а иногда письмо уходит даже после того, как вы отключили его в настройках плагина. Это типично для:
- тестовых и staging-сайтов, где не должны уходить внешние письма;
- магазинов WooCommerce, где нужно оставить только часть уведомлений;
- сайтов с несколькими плагинами, каждый из которых шлёт свои письма;
- проектов, где почтовый сервер ограничивает отправку и важные письма теряются среди лишних.
Диагностика: откуда именно уходят письма
Прежде чем что-то отключать, нужно понять источник. В WordPress письма могут отправляться через wp_mail(), а поверх него — ядро, WooCommerce, формы обратной связи, плагины подписки и безопасности. Если просто отключить всё подряд, можно сломать сброс пароля, подтверждение заказа или уведомления администратору.
Что проверить в первую очередь
- Настройки WooCommerce:
WooCommerce → Настройки → Emails. - Настройки плагинов форм: Contact Form 7, WPForms, Fluent Forms и т. п.
- Есть ли SMTP-плагин, который только доставляет почту, но не управляет тем, что именно отправляется.
- Не дублируются ли уведомления из-за нескольких администраторов или нескольких получателей в настройках.
Если нужен быстрый технический след, временно включите логирование исходящих писем через SMTP-плагин с журналом отправки или через отдельный сниппет, который будет записывать тему и адресата в лог. Это помогает понять, какой код вызывает отправку.
Пошаговое решение: отключаем лишние письма через фильтр
Самый надёжный способ — перехватить отправку через фильтр pre_wp_mail. Он позволяет остановить письмо до фактической отправки. Это удобно, если нужно отключить не всё подряд, а только определённые темы или адресатов.
Ниже пример: блокируем письма на тестовом сайте, но оставляем сброс пароля и уведомления WooCommerce о заказах. Код можно положить в мини-плагин или в functions.php дочерней темы, но для продакшена лучше отдельный mu-plugin.
<?php
add_filter( 'pre_wp_mail', function( $pre, $atts ) {
if ( ! defined( 'WP_DEBUG' ) || ! WP_DEBUG ) {
return $pre;
}
$to = isset( $atts['to'] ) ? (array) $atts['to'] : array();
$subject = isset( $atts['subject'] ) ? (string) $atts['subject'] : '';
// Пример: на staging отключаем почти все письма, кроме критичных.
$allowed_subjects = array(
'Сброс пароля',
'New order',
'Заказ оформлен',
);
foreach ( $allowed_subjects as $allowed ) {
if ( stripos( $subject, $allowed ) !== false ) {
return $pre;
}
}
if ( ! empty( $to ) ) {
error_log( 'Blocked mail to: ' . implode( ', ', $to ) . ' | subject: ' . $subject );
}
return true; // останавливаем отправку
}, 10, 2 );Логика здесь простая: если тема письма не входит в список разрешённых, отправка прерывается. Это не универсальное решение для всех проектов, но для staging и тестовых стендов оно работает предсказуемо.
Если нужно отключить только уведомления WooCommerce
У WooCommerce есть собственные классы уведомлений. Их можно отключать через фильтр woocommerce_email_enabled_{$email_id}. Это точнее, чем рубить всю почту на уровне WordPress.
<?php
// Отключаем только письма о новом заказе для администратора.
add_filter( 'woocommerce_email_enabled_new_order', '__return_false' );
// Отключаем письма о возврате средств клиенту.
add_filter( 'woocommerce_email_enabled_refunded_order', '__return_false' );
// Отключаем письма о завершённом заказе.
add_filter( 'woocommerce_email_enabled_completed_order', '__return_false' );Список email_id зависит от версии WooCommerce и включённых уведомлений, но этот подход штатный и безопаснее, чем править ядро или шаблоны писем.
Сравнение подходов: плагин, код или SMTP
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройки плагина | Если письмо создаёт конкретный плагин и у него есть переключатель | Не всегда покрывает системные письма WordPress |
| Код через фильтры | Если нужно точечно отключить часть уведомлений | Требует аккуратной проверки после обновлений |
| SMTP-плагин | Если проблема в доставке, а не в генерации писем | Не отключает лишние уведомления, только меняет способ отправки |
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой в админке. Нужно убедиться, что письмо действительно не уходит, а нужные уведомления продолжают работать.
- Сделайте тестовый заказ или тестовую регистрацию.
- Проверьте, что отключённое уведомление не пришло на почту.
- Убедитесь, что критичное письмо, например сброс пароля или письмо о новом заказе, всё ещё отправляется.
- Посмотрите лог почтового плагина или
error_log, если вы добавляли запись в лог.
Если письмо всё ещё приходит, значит оно отправляется не тем механизмом, который вы отключили. Тогда ищите второй источник: другой плагин, кастомный код или отдельный SMTP-обработчик.
Частые ошибки и как их исправить
Отключили не то письмо
Самая частая ошибка — фильтровать по теме письма, а не по конкретному идентификатору или источнику. Тема может меняться из-за перевода, шаблона или обновления плагина. Если есть штатный фильтр плагина, используйте его вместо сравнения строк.
Сломали сброс пароля и регистрацию
Если вы перехватываете pre_wp_mail слишком агрессивно, можно случайно заблокировать системные письма WordPress. Для продакшена лучше ограничивать отключение по домену, роли пользователя, среде staging или списку разрешённых уведомлений.
Проверяли только админскую почту
Иногда письмо уходит не администратору, а клиенту, менеджеру или нескольким адресатам сразу. Проверяйте все получатели, особенно если в WooCommerce настроены дополнительные email-адреса.
Оставили код в теме вместо мини-плагина
Если код лежит в теме, при смене темы он исчезнет. Для постоянной логики лучше вынести его в отдельный mu-plugin или небольшой кастомный плагин. Так вы не потеряете настройку после обновления дизайна.
Практические советы по безопасности и производительности
Если вы отключаете письма на тестовом сайте, не полагайтесь только на визуальные настройки. Лучше явно ограничить отправку по среде. Например, на staging можно блокировать исходящую почту целиком, а на production оставить только нужные уведомления.
Для этого удобно использовать проверку домена сайта или константу окружения, если она у вас уже заведена в проекте. Не стоит отправлять реальные письма с тестового стенда на боевые адреса: это создаёт шум и может раскрыть внутренние процессы проекта.
Если вам нужно не отключение, а контроль над уведомлениями и чистка лишних дублей в админке, в ряде проектов помогает связка с Clearfy Pro, но только если задача касается именно типовых настроек и дублей, а не кастомной логики отправки.
Когда лучше не трогать код
Если письма генерирует платёжный модуль, CRM-интеграция или подписка с критичной бизнес-логикой, сначала проверьте документацию плагина. Иногда отключение через код приводит к тому, что письмо не только не уходит, но и не фиксируется как событие в системе. В таких случаях безопаснее отключать уведомление штатной настройкой или через отдельный фильтр конкретного плагина.
Рабочий ориентир простой: если вы можете назвать точный тип письма и точный источник, отключайте точечно. Если нет — сначала найдите, кто именно его отправляет, и только потом вмешивайтесь в код.