Vestnik — транзакционные email-уведомления для MODX3

Vestnik — это компонент для MODX3, который превращает события вашего сайта
в письма. Произошло событие (регистрация, заказ, публикация, оплата) — нужным
людям автоматически уходит письмо по заранее настроенному шаблону. Всё
настраивается в админке, без программирования; для нестандартных случаев есть
простой вызов из сниппета или из кода.


Зачем это нужно

На любом живом сайте постоянно нужно кого-то о чём-то оповещать: сказать
клиенту, что заказ принят, менеджеру — что пришла заявка, администратору — что
зарегистрировался новый пользователь. Обычно это решается «на коленке»: в
шаблоне или в чанке прямо вызывается mail()/PHPMailer, тексты писем зашиты в
код, список получателей — тоже. Любая правка текста письма превращается в
редактирование PHP, а отследить, что и кому реально ушло, почти невозможно.

Vestnik наводит здесь порядок. Он разделяет три вещи, которые обычно
перемешаны:
— СОБЫТИЕ (что произошло),
— ПРАВИЛО (кому и по какому шаблону на это реагировать),
— ШАБЛОН (как выглядит письмо).
Всё это редактируется в админке, а не в коде.

Как это работает

Событие -> правило -> получатели -> шаблон -> очередь -> отправка по крону -> журнал.

1. На сайте происходит событие. Это может быть штатное системное событие MODX
(регистрация, вход, сохранение/публикация документа и т.п.) или ваше
собственное событие с произвольным именем (например order.paid).
2. Vestnik находит активные правила, заведённые на это событие.
3. Для каждого правила определяются получатели и рендерится шаблон с
подстановкой данных события.
4. Готовое письмо кладётся в очередь.
5. Крон разбирает очередь и отправляет письма, а результат каждой отправки
пишется в журнал.

Мгновенной отправки нет. Все письма проходят через очередь и
уходят по крону. Это защищает сайт от «подвисания» на отправке и от потери
писем при всплесках нагрузки, а также даёт повторные попытки при сбое SMTP.

Чем полезен — коротко по пунктам

+ Тексты писем и получатели живут в админке, а не в коде. Контент-менеджер
может поправить письмо без разработчика.
+ Гибкие получатели: администратор (адрес из настройки), сам пользователь
события (адрес берётся из данных события), явный адрес (или несколько), либо
все активные пользователи выбранной группы MODX.
+ Шаблоны на нативном синтаксисе MODX: [[+username]], экранирование
[[+fullname:htmlent]], условия и ветвление через стандартные output-фильтры.

+ Данные для писем передаются просто: любой ключ из JSON/массива становится
плейсхолдером [[+ключ]] в теме и теле письма.
+ Три способа «дёрнуть» событие:
— штатные события MODX — ловятся плагином автоматически;
— вызов из шаблона/чанка сниппетом [[!vestnik_notify? ...]];
— вызов из кода стороннего компонента:
$modx->services->get('Vestnik')->trigger('shop.order.new', $data, 'component');
+ Надёжная доставка: очередь + повторные попытки + журнал с результатом каждой
отправки. Всегда видно, что ушло, что не ушло и почему.
+ Кнопка «Тестовая отправка» прямо в шаблоне — проверить вёрстку письма на
произвольный адрес, не создавая реальное событие.
+ Точки расширения для разработчиков: собственные системные события
OnVestnikBeforeQueue, OnVestnikBeforeSend, OnVestnikAfterSend позволяют
вмешаться в работу Vestnik плагином, не трогая его код (отменить отправку по
условию, дополнить данные шаблона, вести свою статистику, дёргать вебхук).
+ Ядро спроектировано с заделом под другие каналы (Телеграм, SMS); в текущей
версии доступен email.

Типовые сценарии применения

— Интернет-магазин: письмо покупателю о принятом/оплаченном заказе и
одновременно уведомление менеджерам (группе пользователей) о новом заказе.
— Регистрация/активация пользователей: приветственное письмо новому
пользователю на его же адрес.
— Обратная связь и заявки: письмо администратору о новой заявке с формы.
— Публикация контента: уведомление редакции о новом/опубликованном материале.
— Безопасность и контроль доступа: как только кто-то вошёл в админку —
администратору сразу приходит письмо. Зашёл в панель управления — получил
уведомление. Это простой способ вовремя заметить чужой вход и держать под
контролем, кто и когда работает в системе.
— Любые бизнес-события вашего компонента: придумываете имя события, заводите
правило, вызываете trigger() из своего кода — и письмо уходит.

Почему email, а не мессенджеры

Многие сейчас шлют уведомления в мессенджеры — это модно и быстро. Но у такого
подхода есть фундаментальная проблема: мессенджер вам не принадлежит и в любой
момент может исчезнуть или стать недоступным.

Мессенджеры приходят и уходят. Их закрывают, продают, «сворачивают», блокируют:
— Skype — закрыт компанией Microsoft в мае 2025 года;
— ICQ («аська») — легендарный мессенджер, окончательно закрыт в 2024 году;
— AOL Instant Messenger (AIM) — закрыт в 2017 году;
— Windows Live Messenger (MSN) — закрыт в 2013 году;
— Google Talk / Hangouts — закрыты и не раз переименованы.
Доступ к мессенджерам в разных странах то и дело ограничивают и
блокируют по политическим мотивам — сегодня канал работает, а завтра
пользователи в целой стране не могут его открыть. Показательный пример —
Телеграм: его блокировали в ряде стран (в России,
в Иране, Китае и других), а в 2024 году во Франции задержали его основателя.
Мессенджер вроде бы жив и популярен, но доступ к нему в любой момент зависит от
политических решений и позиции его владельцев.

Другой пример — мессенджер MAX. Чтобы отправлять в него сообщения программно,
нужно быть юридическим лицом: пройти регистрацию, подтвердить
статус. Для рядового разработчика или владельца небольшого сайта это лишняя
бюрократия там, где для email достаточно указать адрес. При этом сам MAX уже
удалили из App Store — то есть даже установить и открыть приложение не всегда
получится. И вот что важно: ни на бюрократические требования, ни на удаление
приложения из магазина рядовой разработчик или пользователь повлиять никак не
может — эти решения принимают за него.

Строить на всём этом систему уведомлений бизнеса — значит зависеть от чужих
решений, которые вы не контролируете.

Email — это другое. Электронная почта работает по открытому стандарту (SMTP)
несколько десятилетий, у неё нет единого владельца, который мог бы её
«выключить». Адрес есть у каждого, письма доходят из любой страны в любую, а
сам протокол переживёт любой отдельный сервис. Поэтому для важных,
транзакционных уведомлений (заказы, оплаты, доступ, безопасность) email был и
остаётся самым надёжным и предсказуемым каналом — в отличие от мессенджеров,
на которые нельзя полагаться вдолгую.

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

Доступен в репозитории MODX:
https://extras.modx.com/package/vestnik