[meeting] 2025-09-03 core mailer beta planning

Mailer module namespace conflict

The experimental core mailer module namespace conflicts with a preexisting contrib mailer project. The participants expect that the transition from experimental to a stable implementation (making the module superfluous) could take a couple of releases. The current draft MR which proposes to introduce a mailer_experiment module isn’t ideal, especially when the module approaches its end state. Members of the group proposed mails or email as an alternative. The group decided to try it with mailer_symfony instead.

• 📌 Resolve potential namespace conflict with contrib mailer module Active

It was briefly discussed how the transition from experimental to stable could be performed. One way would be to introduce a new mailer_legacy module containing legacy services (mail manager) in the same release the new mailer becomes stable (and default). Existing sites which haven’t enabled mailer_symfony yet will enable mailer_legacy during the upgrade and continue to use the old API for core mail.

Backwards compatibility

The group briefly touched on backwards compatibility. When the core mailer becomes stable, a lot of modules either need a complete rewrite or will become obsolete. In order to help with that, it's important to provide specific migration documentation. E.g., modules which implemented hook_mail_alter before in order to add a note to every outgoing mail should implement hook/event/whatever. etc.

Also when the core mailer becomes stable, multiple contrib Symfony Mailer integration modules will become obsolete. It is also important to provide documentation on how to migrate from them.

Sending emails defined by another module

In some version of the MR in the template/controller draft issue, the call site looks quite complex. Members of the group point out that this could be a problem. E.g., A custom project which needs a button which (re)sends a password reset or an order receipt, would need to copy and maintain the call site. If that piece is complex, then that means more technical debt for a custom project.

The group discussed whether sending emails defined by another module really should be a supported use case. Projects like ECA would benefit from that.

On the other hand, if the module itself decides whether or not to provide a dedicated API for notifications, then that could include other channels as well. E.g., users might want to receive password resets via an instant messaging app.

There are also types of mails where it isn’t obvious why other modules would want to trigger them. One example is the update status notification. Exposing that as a public API doesn’t seem desirable.

The group doesn’t take a decision whether to go one or the other way. Whether or not to expose triggering an email as a public API may end up being the decision of the email sending module.

• 📌 Introduce email yaml plugin and an email building pattern known from controllers Active

Altering emails defined by another module

The group agrees that it is desirable to provide a registry of all emails available on a site. This should also include very simple emails. In that case, the altering module might not see any parameters but only that a message (subject, (un-)rendered body) of a certain module/key combination is about to be sent.

Access to the Symfony Email object

The group discussed which role the Symfony Email object should be playing in the upcoming API. Several members pointed out that Symfony has a history of introducing breaking changes in a rhythm which is difficult to keep up in Drupal projects (this is especially true for contrib modules which are expected to support multiple core versions).

On the other hand, direct access to the Symfony Email object allows for advanced use cases.

One option to tackle this dilemma is to ensure that developers do not need to interact with the Symfony Email object when performing standard email building activities.

Next meeting:

Next planning meeting takes place October 1st at 4PM UTC+2.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.