The format of notification emails could use some improvement

[Skirmisher]

It's always hard to parse out the text of the post from the rest of the email template, mainly because "The text of the reply is shown below:" only has a single line break after it... Having two links at the top is also really distracting, especially the huge unsubscribe link which really belongs below the post text (might even want to do that with the topic link as well, but I don't feel as strongly about that one).

Those are the main pain points for me, but here's a few other notes:

• The subject line doesn't necessarily need to have "Topic reply" etc., since it obscures the post title (which is not reproduced in the body of the email either)
• Similar to the other elements, the poster's username is also obscured, buried at the end of a sentence
• The plain-text post formatter doesn't handle quotes well, with no line prefix for the quoted text, only sticking the "Quote [from: username on ...]" header in front of the first line without any line break or spacing at all

As an example of notifications that are nicer to read, I generally like how GitHub's notification emails are formatted. For new threads (issues/PRs/etc.) and comments:

• The subject line is formatted "[OrgName/RepoName] Thread Title (PR #69)"
• The sender name in the header is set to the author of the post
• The body:
  
  • immediately begins with the post's text content
  • followed by post-specific metadata if applicable
  • then is capped off with a generic footer with origin & unsubscribe links
  • and each section is separated by <hr>

Now, I of course don't expect to drastically alter how SMF's emails work (especially with downstream patches). But just shuffling the existing pieces around would be a great improvement on its own.

[viviridian]

I wonder whether this is something that packages can fiddle with, or if it'll require directly modifying smf. Not sure if there have been any modifications to this smf or if it's vanilla with packages on top

I also don't know if there are limits on packages. back when I was doing stuff with smf I just edited php in prod

[snow]

I wonder whether this is something that packages can fiddle with, or if it'll require directly modifying smf. Not sure if there have been any modifications to this smf or if it's vanilla with packages on top

Any modifications other than the "lightbox" patch are in the F9 repo. Or rather, should be. (If you find any inconsistencies, please let me know, because that's not intentional!)

They all "compile" to the SMF mod .tar.gz archives, and then can be installed through the admin panel.

As for the email templates, they can be modified per-theme, specifically in Themes/$theme/languages/EmailTemplates.english.php (a github link to the default, for reference).

I also don't know if there are limits on packages. back when I was doing stuff with smf I just edited php in prod

That depends. If you're working with hooks, you're stuck with wherever the SMF devs decided to stick a call_integration_hook call, but at least it'll survive minor updates. There's a way to patch files via XML, but... at that point I'd rather just use patchsets.