Change in behaviour re mail

Support
1

Suddenly after the latest update Discourse sneds mails with:

“Someone replied to a topic you are Watching.” prefacing every email. All my users are complaining heavily, and none have changed any email settings.

All say it is very annoying.

So, what has happened, and how can we turn this off and revert to normal plain behaviour? I don’t think this has been well implemented, and the developer did not even care to check it, as watching is spelt with a needless capital W.

2

I think the source of the annoyance for Andrew’s community members is %{header_instructions}.

That token expands to a fairly large block of boilerplate (“do not reply…”, links, instructions, etc.) and it appears at the very top of the email body in many notification templates. For experienced users it dominates the message and reads as nagging rather than helpful.

There’s currently no site-wide setting to disable or relocate it. To remove it, an admin has to edit every email template individually under Admin → Email → Templates.

On current latest-release (I’m on latest-release +17), it should be possible to address this centrally with a Rails script for templates that already have DB overrides, e.g. stripping %{header_instructions} when it appears at the start of the body. That part is straightforward and uses the EmailTemplate model.

Applying the same change to all stock templates (including those without existing overrides) would require creating overrides by pulling in the default template bodies via internal lookup APIs. That’s feasible, but it depends on Discourse internals and would need a maintainer to review/validate before being recommended broadly.

So the underlying issue isn’t just the content of %{header_instructions}, but that it’s effectively global boilerplate with no admin-level toggle, and removing or moving it requires per-template manual work or unsupported scripting.

3

@Ethsim2 thanks that’s really great. But why did this suddenly change? I am no expert at reading or even locating change logs.

4

@Andro yep - totally fair question.

The “suddenly” part is because %{header_instructions} isn’t something you changed locally: it’s a core-provided block that Discourse injects into a number of notification emails. If core changes its wording or when it’s included, everyone will notice immediately even if no admin settings were touched.

I don’t want to overclaim without a specific commit reference, but the most likely cause is a recent core change to the default text that %{header_instructions} expands to for watched-topic notifications (for example adding the “Someone replied to a topic you are Watching.” line), or to when that block is included in the email body.

How to confirm where it’s coming from:

  • In Admin → Email → Email Settings → Templates, look at the notification templates your users receive (watched / tracked / replied / mentioned).
  • If the body starts with %{header_instructions}, that’s the source of the new prefacing text.
  • Removing it, or moving it below %{message} / %{context} (or even %{reply_instructions}), will revert to the previous “plain” behaviour.

Unfortunately there isn’t currently a site-wide toggle for this. Each affected template has to be adjusted individually, which is why this feels abrupt and hard to control when core behaviour changes.

If you’re on hosted Discourse, the practical workaround is just editing the small handful of templates your users actually receive, rather than all of them.

1 Like
5

These previews were added a few days ago

3 Likes
6

So just removing %{email_preview} from the templates would fix this?

1 Like
7

The word Watching is often capitalized in reference to the specific Discourse function.

I’m always watching for interesting topics to appear. But I’m Watching certain topics for any new replies.

2 Likes
8

And then Tracking, etc, as indicated in the topic notification status dropdown.

9

To be honest, I would not have figured that out. I get it, but its a bit unusual, in a way.

1 Like
10

Thanks, that makes sense.

So in this case the sudden change Andro is seeing comes from %{email_preview} being added recently (PR #36657), which explains why it appeared overnight without any admin changes.

From an admin point of view the pain point is similar either way: it’s core-injected content at the top of the email body, and there’s currently no site-wide toggle to disable or reposition it. The only workaround today is editing the affected email templates and removing or moving %{email_preview} (just like %{header_instructions}).

For hosted customers in particular, that’s why this feels abrupt — defaults changed, but there’s no supported global control.

11

The preview strings can also be overridden - you can search for the specific string or .preview and then Ctrl-F search user_notifications to find them.

From the commit message:

For html emails this preview text is hidden with display: none to
prevent it appearing within the body of the email. For the plain text
version of the email it will appear within the body of the email.

For which users is this message appearing? It shouldn’t be.

In my email client, I see in the source:

<div class="email-preview" style="display:none"><p>Someone sent you a PM.</p></div>

and it’s hidden in both Thunderbird and Gmail (web).

2 Likes
12

For reference, this is how the new preview text is surfacing in Outlook for iOS for me - it’s not just an inbox snippet; it becomes the first visible line associated with the message, which is what users are reacting to.

Outlook for iOS Mail screenshot showing “Someone replied to your post.” appearing prominently above the message content, with FW/[PM] prefixes visible
Outlook for iOS Mail screenshot showing “Someone replied to your post.” appearing prominently above the message content, with FW/[PM] prefixes visible1206×687 134 KB

This seems consistent with %{email_preview} being added recently: even if intended as hidden preheader text for HTML emails, in practice it’s highly visible to users (at least in some clients / delivery paths), which explains the sudden complaints.

13

This is probably intentional since it’s surfacing the reason for the email into the message preview. I’d hazard a guess that without it, the message preview is generally not useful?

14

That makes sense, and I agree that having some meaningful preview text is generally useful.

The issue users seem to be reacting to (at least in Outlook for iOS and similar clients) is that this preview text isn’t just influencing the inbox snippet - it visually reads as part of the message body itself, appearing ahead of the actual content. In practice that feels repetitive and noisy rather than helpful.

There’s also a bit of a tension in the current wording: the anonymous phrasing (“Someone replied…”) is helpful from a privacy and screenshot-sharing point of view, but in day-to-day use it’s less informative than sender-aware previews, where users mainly want to know who replied and whether it needs attention.

So it’s less about whether preview text should exist at all, and more about whether the current, fairly rigid implementation degrades the reading experience in some clients or delivery paths. A client-sensitive approach, or a supported way to reposition or disable it, would likely address most of the complaints without losing the benefit of improved previews.

1 Like