Vestnik

Vestnik — Transactional Email Notifications for MODX 3

Vestnik turns your site's events into emails. When something happens (registration, order, payment, publishing, a contact request) the right people automatically receive an email based on a predefined template. Message texts, recipients and rules are all configured in the manager — no code changes required. For custom cases you can trigger events from a snippet or from your own component's code.

Vestnik separates three things that are usually tangled together inside chunks and plugins: the EVENT (what happened), the RULE (who to notify and with which template) and the TEMPLATE (how the email looks). Every message follows one predictable path: event → rule → recipients → template → queue → cron send → log.

Features

• Configure everything in the manager (CMP): rules, templates, queue, log — no programming needed.
• Templates use native MODX tag syntax: [[+username]], escaping [[+fullname:htmlent]], conditions and branching via standard output filters.
• Flexible recipients: administrator (address from a system setting), the event user itself, an explicit address (or several), or all active members of a chosen MODX user group.
• Passing data is simple: any key from the array/JSON becomes a [[+key]] placeholder in the subject and body.
• Three ways to fire an event:
  • standard MODX system events (caught automatically by a plugin);
  • a snippet: [[!vestnik_notify? &event=... &data=...]];
  • from code: $modx->services->get('Vestnik')->trigger('order.paid', $data);
• Reliable delivery through a queue: cron-based sending, automatic retries on SMTP failure, and a log with the result of every send.
• A "Test send" button to preview an email's markup at any address.
• Extension points for developers — custom system events OnVestnikBeforeQueue, OnVestnikBeforeSend, OnVestnikAfterSend: cancel a send conditionally, enrich template data, collect your own stats, or call an external webhook — all without touching the component's code.
• The core is designed with other channels in mind (Telegram, SMS); the current version ships with email.

Typical use cases

• E-commerce: notify the customer about their order and alert managers (a user group) about a new order.
• Registration: a welcome email to a new user.
• Contact forms: notify the administrator about a new request.
• Publishing: notify editors about new content.
• Any business event of your own component via a trigger() call.

Requirements

• MODX Revolution 3
• A configured cron job (to send queued emails)
• Working mail delivery on the server (SMTP/mail)

3.1.5-pl

• Queue: parallel runs can't send the same email twice; emails stuck after a crash return to the queue in 15 minutes
• Queue: retries wait a growing delay (new setting vestnik_retry_delay); failed emails can be sent again from the log
• OnVestnikBeforeSend: 'prevent' postpones an email without blocking the queue, new 'cancel' moves it to the log as cancelled
• Templates: placeholders missing from the data render empty and filters like :default work on them; leftover tags are removed
• Lost emails are always written to the MODX error log; invalid JSON in the snippet's &data no longer creates an email
• Attachments: an empty vestnik_attachments_path now means core/components/vestnik/attachments/ instead of the site root; MODX configuration, PHP and hidden files can never be attached; the snippet no longer accepts attachments
• Log: email bodies and old entries are removed automatically (new settings vestnik_log_body_days and vestnik_log_keep_days)
• Debug mode without a test address no longer sends emails to real recipients
• Queue: emails over a lowered attempt limit move to the log instead of staying in the queue forever
• Group recipients: blocked users no longer get emails; recipient name falls back to the username
• Full English translation of the Docs tab
• Removed unused code and assets; installed sites are cleaned up on upgrade
• Templates are rendered for each recipient; new placeholders [[+recipient_email]], [[+recipient_name]], [[+recipient_username]], [[+recipient_id]]
• Removed the rule Source and template Language fields, which had no effect; their columns are dropped on upgrade
• Plain text templates keep text like Name [email protected] instead of losing it
• cron.php finds MODX by its own path, so a core outside the site root works
• Manager shows server and network errors instead of failing silently
• OnVestnikAfterSend gets a copy of the email, the result, the error and the log entry id

3.1.4-pl

• Security: MODX and Fenom tags inside event data are no longer executed, only tags written in the template itself
• Security: email previews in the manager run in a sandboxed iframe, scripts from an email can't run
• Security: vestnik_view, vestnik_save and vestnik_remove are now enforced; the policy is granted to the Administrator group, other manager groups need it assigned manually
• Security: removed the unused Template/PreviewHtmx endpoint

3.1.3-pl

• Email assembly reworked to avoid spam filters (Yandex in particular): body is always UTF-8 and is no longer converted to HTML entities (MODX's modPHPMailer::send() did that when mail_inlinestyle_inline is on); CSS inlining is still applied
• Body is wrapped into a complete HTML document with a declared charset; plain-text templates keep their line breaks
• A plain-text alternative part is generated from the HTML (multipart/alternative)
• Message-ID uses the sender's domain instead of localhost.localdomain when sent from cron (CLI); X-Mailer header removed
• Vestnik uses its own modPHPMailer instance (SMTP/DKIM still come from mail_* system settings), so its headers never leak into other components' emails

3.1.2-pl

• Log grid: view button, context menu item and double-click open the log entry (recipient, sender, status, error, attachments, email body preview)
• Log now stores sender, recipient name, email body and attachments (columns are added automatically on package upgrade)