Automated Support & Changelog Emails
Super Speedy Emails can automatically email the people who own a product whenever there’s something to tell them — for example, sending the changelog for a plugin to everyone who bought it. This page explains how the feature works, how to set it up safely, and how the underlying filter system lets developers control who gets an email and what it says.
The system is built in two layers:
- A generic, vendor-neutral engine in the core plugin. It fans out over a product list, resolves owners, applies your audience rules, the suppression gate and a per-day guard, then queues, sends and logs. It knows nothing about changelogs.
- A changelog implementation that lives in a small companion plugin (Super Speedy Plugins — Changelog Emails). It hooks the filters to read each plugin’s
readme.txtand decide when there’s a new version worth sending. The core ships no changelog code — the companion is a worked example you can install, read, and adapt.
You can use the companion’s changelog behaviour as-is, or hook the filters described below to send anything you like — security advisories, maintenance notices, renewal reminders — to product owners.
Table of Contents
What a Support Email is
A Support Email is a saved record you create in the admin. It has four parts:
- Products — a checklist of the products this email is about. This is the fan-out axis: the engine sends one email per product to that product’s owners. An owner of three of the ticked products gets three separate emails, each about one product (with its own changelog and its own history).
- Audience rules (optional) — narrow each product’s owners by purchase recency (bought within / more than N days ago, by first or last purchase), combined with ALL or ANY. Leave empty to email every owner.
- Subject + body — the content, with placeholder tokens. The subject defaults to
Updates available for {product_name}. - The filters — optional PHP that decides who receives it and what it says (the changelog companion plugin is the worked example).
Key things to understand first
- Bundle owners are included automatically. If a customer bought a bundle that contains the plugin, they count as an owner of that plugin.
- It has its own unsubscribe. Support emails use the
product_supportcategory, whose opt-out is separate from your marketing opt-out. Someone who left your newsletter still gets product updates; someone who turned off product updates still gets your newsletter. (See Unsubscribes & the Preference Centre.) - At most one per product per person per day. A built-in per-day guard means a given product can’t email the same customer twice in a calendar day, no matter how many times you click Send or how the cron fires.
- “Is there news today?” is the filter’s job. The core doesn’t track versions. Whether a product has anything to send right now is decided by the
sse_should_send_support_emailfilter — for changelog emails, the companion answers “yes” only when the version advanced.
The safe baseline (read this first)
The single most important thing to understand about the changelog companion: the first time it sees a plugin, it sends nothing. It records the plugin’s current version as a starting point (“baseline”) and emails nobody. Only when the version moves past that baseline does anyone get an email.
This means you can switch the feature on for a whole catalogue without accidentally emailing thousands of customers a changelog they’ve already read. So a normal rollout is:
- Activate the changelog companion plugin and create a Support Email with your products ticked.
- Send now once — this records baselines and sends nothing (0 emails).
- From then on, each real plugin update emails its owners once.
Setting it up
Go to Super Speedy Emails → Support Emails and click Add Support Email.
1. Name it and pick products
Give it a name (e.g. “Plugin updates”). In Products, tick the individual plugins whose owners should receive update emails. Use Select all / the filter box for long catalogues.
- Don’t tick bundles or service products. Bundle owners already receive each component plugin’s email automatically (via bundle expansion), so ticking the bundle itself would be wrong — a bundle has no single changelog. Service products have no changelog at all.
- For the changelog case, each ticked product needs a plugin slug mapped to it in the companion plugin so it knows which
readme.txtto read. A product with no mapping simply sends nothing (it fails safe).
2. Audience rules (optional)
Leave empty to email every owner of each ticked product. To narrow by recency, add rules like “bought within the last 365 days” or “bought more than 30 days ago”, combined with ALL (every rule must match) or ANY (at least one). These run on top of the product owners. For anything more specific (licence status, region, …), use the sse_support_email_should_send_to_user filter — see below.
3. Write the email
Set the Subject (the default Updates available for {product_name} works for most cases — {product_name} is filled per product) and the Body. The editor lists the available placeholders. For changelog emails the body is supplied by the companion plugin’s content filter, so you can leave a simple default. Emails are plain text — links are made clickable automatically.
Placeholders (work in subject and body): {product_name}, {first_name}, {email}, {unsubscribe_url}, {manage_url} (preference-centre link), {site_name}, {site_url}.
4. Preview before you send
Click Preview. This evaluates each ticked product without sending anything and streams a per-product row:
| Column | Meaning |
|---|---|
| Total owners | How many people own this product (including via bundles). |
| Will receive | How many would actually get an email on this run. |
| Will NOT receive | The rest, with the reason: no update pending / already sent today / unsubscribed-or-suppressed / filtered by your rules or the per-user filter. |
Preview is your safety check, and it never changes any state. If a product shows “No update pending”, there’s nothing to send for it yet — that’s normal until a version advances.
5. Send
Save the Support Email, then click Send now. It evaluates each product and queues the emails, which go out through the normal sending queue respecting your test mode (Live / Log-only / Redirect — see Test Modes). Always rehearse in Redirect mode first so every email comes to you.
Manual send vs. the daily cron
By default, sending is manual — you click Send now when you ship an update. There’s an optional daily check (sse_support_email_check, off by default) that runs every active Support Email on a schedule. Even with it on, nothing goes out unless the should_send filter says there’s news, and the per-day guard prevents same-day duplicates.
The filter system: deciding who and what
The engine hard-codes no changelog logic. At each step it asks a filter — code you (or the companion plugin) hook — to decide. There are four, each receiving the running value plus a single SSE_Support_Context object:
| Hook | When | Decides |
|---|---|---|
sse_should_send_support_email | once per product (before owners load) | Is there news for this product right now? (default: yes) |
sse_support_email_subject | per product / recipient | The subject line (optional — the GUI subject with {product_name} is the no-code default) |
sse_support_email_content | per product / recipient | The body — returns { body, name } |
sse_support_email_should_send_to_user | once per owner | Should this person get it? (default: yes) |
Plus the sse_support_email_sent action, which fires once per queued email on a real send (never during Preview) — the changelog companion uses it to advance its stored version.
The full developer reference, signatures and worked examples are in Automated Support Emails — Developer Guide and the worked example How We Send Our Changelog Emails.
Why you can’t spam by accident
Three things protect customers:
- The
should_sendfilter — for changelog emails, it only returns “yes” when the version actually advanced, so a blast only happens when there’s genuinely something new. - The per-day guard — a given product won’t email the same person twice in a calendar day, so re-clicking Send or an overlapping cron run can’t double-send.
- The suppression gate — anyone who unsubscribed from product updates, or was globally suppressed by a hard bounce or spam complaint, is removed automatically.
Before you go live — checklist
- [ ] The changelog companion plugin is active, with your products mapped to plugin slugs.
- [ ] Settings → Sending: a Product support sender identity (From / Reply-To) is configured.
- [ ] A Support Email exists with the right products ticked and saved Active.
- [ ] Ran Send now once as a baseline — it sent 0 and recorded current versions; re-running Preview now shows “No update pending” for everything.
- [ ] Rehearsed a real bump in Redirect test mode and confirmed the email looks right, with a working “unsubscribe from product updates” link.
- [ ] Switched to Live. From now on: ship an update → Preview → Send now.
- How We Send Our Changelog Emails (Worked Example) — the real changelog implementation, end to end.
- Automated Support Emails — Developer Guide — the full filter reference.
- Editing Email Templates — change the wording and footer.
- Unsubscribes & the Preference Centre — how the separate product-update opt-out works.
- Test Modes — rehearsing a blast safely.
