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?

[callumbw95]

Hi All,

Just taking a look into this, as this has been sitting for a while. It looks like there has not been much movement if any in regards to the notification API in the last few years. However it seems the topic has not been forgotten, and more recently in the last few weeks it appears that a notification API has come up on the radar again on a recent ​Core Commitors Check-in post - July 2025:

Re-engage with prior explorations from the Notifications API and WP Notify efforts to assess paths forward for more consistent, dismissible admin notices and improved admin interactions

Seeing as this new API looks to cover most of what this ticket is regarding, it is probably safe to close this ticket down for now, and I have attached the close tag. However if there is more conversation to be had around this, please do continue the conversation and remove the tag. 😃

[markcallen]

That's fine, I'd given up on anything ever happening with this anyway.

I maintain that all notifications/emails should be triggered by an action - with subsequent calls to wp_mail(), so they can be controlled by developers - either through replacement emails, or setting up other channels (WhatsApp, SMS, RCS... whatever), along with leaving wp_mail() intact for fallback (and backward compatibility where existing plugins have replaced it).

I think it's a very simple implementation and would not take huge effort, but understand there may be broader considerations I'm not aware of.

[SirLouen]

Replying to markcallen:

That's fine, I'd given up on anything ever happening with this anyway.

I maintain that all notifications/emails should be triggered by an action - with subsequent calls to wp_mail(), so they can be controlled by developers - either through replacement emails, or setting up other channels (WhatsApp, SMS, RCS... whatever), along with leaving wp_mail() intact for fallback (and backward compatibility where existing plugins have replaced it).

I think it's a very simple implementation and would not take huge effort, but understand there may be broader considerations I'm not aware of.

The whole system has moved into a filter for “full control” (enable/disable and editing subject/bodies).

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.

This proposal maybe was good back in the past, but nowadays it it's massively redundant to the filters. Yes, actions won't get in the way, but as I say, they are simply redundant. Nowadays you cannot do anything with actions that you cannot do with filters (plus multipart is not even supported yet, still in progress). And since filters are not going to go anywhere soon (and even less with a major revamp with actions), I believe that this report has stallen to death.

Use a different server to send (e.g. to benefit from DKIM/SPF)

Possibly I'm missing some context from 9 years ago when this was published, but with phpmailer_init action this is easily manageable.

Looking forward to a more future-proof strategy, the new proposal which aligns better with current standards, is the idea of building up a templating system that could allow fully upgrading to multipart (with all the major improvements associated, like the ability to control for example, RTL emails). Still, wp_mail is pluggable and still, it feels more like a fallback (for those who have not decided to add a plugin to fully override its functionality) than a standalone internal feature.

There are some related issues to this topic like:
#49661
#51717
#15448

Since this is not going to take us anywhere, I think it's time to conclude this as a closure with wontfix or maybelater.