Send emails via an action

[markcallen]

There are a number of ways that you may want to interact with core emails in WordPress. To name two

• Use a different server to send (e.g. to benefit from DKIM/SPF)
• Use custom templates, HTML, multipart etc.

Currently solutions to achieve these things are not ideal. Pluggable functions leave exposure to other core changes and leave no scope for a 'fallback' to default if it is necessary.

Filters for content are inconsistently (if at all) applied leaving some messages totally inaccessible to developers, save through the wp_mail filter - which is hacky at best (try catching a translated message).

My proposal is relatively simple - send all emails in core through an action hook.

do_action( 'wp_mail_{email_id}', $args );

$args of course would carry the necessary elements for the dynamic parts of a message.

An call add_action can then exactly replace what is being done at present to generate the message and make the wp_mail call.

Any developer that wants to interact with the message can then simply remove the core action and add their own - to alter the message and/or send using an alternative mechanism to wp_mail, falling back to it if necessary. Possibilities for developers are then endless.

wp_mail stays in tact and as the hook call replaces current functionality there is no issue with backward compatibility - all existing filters can stay in place.

[johnbillion]

Better control over notifications is an area I've wanted to work on for a while now, but I haven't managed to find the time for it.

Here's a doc I created which lists all of the instances where WordPress sends an email, and the related hooks and filters: ​https://gist.github.com/johnbillion/0a48021de5510c41d517 . These would need to be taken into account for backwards compatibility.

[markcallen]

Replying to johnbillion:

Here's a doc I created which lists all of the instances where WordPress sends an email, and the related hooks and filters: ​https://gist.github.com/johnbillion/0a48021de5510c41d517 . These would need to be taken into account for backwards compatibility.

This is a useful list that clearly shows the inconsistent approach to how emails are filtered and sent. Using filters to disable actions should not, IMO, be the best approach.

My proposal, I believe, leaves everything in place so backward compatibility is assured.

It simply introduces a specific hook per email which can be left alone for everything to stay as is, removed to disable the message, or replaced for developers to do with as they wish.

[markcallen]

Retrieve password email triggered through action

[markcallen]

The attached patch covers one of the wp_mail calls in core - it serves to demonstrate

• Back-compat is covered, it does the same thing when left alone.
• The default action can be adjusted using the pre-existing filters
• The action could be removed, preventing the wp_mail call and remove the need for any of the numerous hacks out there to stop mails being sent by WordPress.
• The action can be replaced - giving a developer complete freedom to use wp_mail (primarily or as a fallback), or any number of third-party email services (e.g. SMTP or API), or even just to a log file for development purposes.

I will patch the rest of the calls to wp_mail if this is something that can be committed.

I'd love to hear any other ideas that give both, full back-compat and total freedom to developers to send emails how they want.

[markcallen]

I understand that this falls within the notifications API proposal (​https://make.wordpress.org/core/2016/10/03/feature-project-proposal-notifications-api/).

This solution - perhaps with some naming changes - manages this. It's backward compatible, can be used to send notifications using any service, not just email and in my opinion makes improves the workflow dramatically. Sending notifications is an action and should be triggered as such.

It's been six month since this was touched. Can we do anything to move it along?

[markcallen]

It's now over three years since this ticket was created.

It reports on the clear issue of sending emails from WordPress but also present a sensible (IMO) solution that is both flexible within WordPress approach and fully backward compatible. It also has adapted code ready to roll (or it was when it was written).

Yet it is still 'awaiting review'.

What is missing to get it reviewed?