Mailer module roadmap: the path to beta and stable

Drupal Symfony Mailer Lite and Mailsystem are part of the old mail system - they are useful to indicate the required features, but the APIs are outdated.

Easy Mail and DSM+ (especially the "Mailer Policy" module), plus many others modules are users of the email API provided by Core. They indicate the required function and suggest what API could be useful.

DSM+ also contains a prototype for the Core mailer. For sure we don't have to copy it, but we can at least reference it for ideas of API and features, given that it is used in many sites.

Low maintenance overhead while still providing the necessary extension points

This sounds like an excellent aim. From the perspective of DSM+, here are some priorities that I see. The referenced issues should provide a good checklist of points for discussion even if we end up making some different choices. If we can try to match DSM+ where possible it would make the transition easier for the sites already using it.

1. ✨ Create new mailer service based on symfony Active is key. Core can provide interface parameters for Contrib even if they aren't used in Core. With the old mail interface we had so many undocumented uses of $message['params'] that were inconsistent between modules, so it would be great to avoid that.
2. ✨ Create a new mailer service to wrap symfony mailer Active hopefully we can at least do some of these things, and match function that's in the old mail system. It seems fine if Core omits some features so long as the services/classes can be overridden by Contrib to add them in.
3. ✨ Events/callbacks for new mailer service Active important to have access to act on emails at all the relevant stages.
4. Policy: component mailer implementations should be swappable, likely as a service but could also be a plug-in. For example we create UserMailer service with function notify() that matches _user_mail_notify().

Some other issues:

• ✨ Migration strategy for moving to Symfony Mailer Active is obviously an important topic. I wrote some ideas, but it doesn't create any problems for DSM+ if it works a completely different way.
• Other issues like ✨ Create a plug-in system to build emails with Symfony Mailer Active , ✨ Create a system for configurable emails in Symfony Mailer Active are just ideas, no problem if they are left to Contrib.

Add configuration UI for the mail delivery layer.

The "full" solution is to have UI plug-ins corresponding to each Transport, which provide a form field for each parameter. There is code for this is in DSM+ and mostly copied into DSM-L. I had the idea that it could live in a separate project Mailer Transport → .

A simple solution is to have a setting to configure the DSN. However we found that GUI admins can find it difficult to understand the required escaping.

I've updated the IS. Hopefully nothing controversial, but if there are any issues then please let's discuss.

I expanded the Background/Motivation quite a lot, including more detail on the existing ecosystem and the importance of continuing to support all the existing features.

I kept the original emphasis on a simple Core making a fresh start, without any ties to existing Contrib. I did balance it by pointing out that it would help site builders if we matched Contrib whenever it did fit out needs, rather than creating a different API with different functions that effectively does exactly the same job.

I added a new emphasis on keeping existing Drupal features not in Symfony. In particular we rely on code living in a callback(hook_mail) and building the email based on params. There are 2 important reasons: context switching and customisability, which are both explained in detail in the specific issues described in the IS and #5. I realise that people are attracted to code like (new Email())->setTo()->setSubject()->setBody()->send(), but I have explored this in detail and I can't see how it can meet all the existing contrib needs. I have got as close to this as I can (it can still be a single line of code with the callback in an anonymous closure), although I found it more readable to create a mailer class with concrete functions for the callbacks.

Of course we can discuss this all further.

Please let's keep this issue a low-noise place. I'd prefer if people could follow here in order to just get updates about the progress, nothing more, nothing less. See the 🌱 Single Directory Components module roadmap: the path to beta and stable Active for how this kind of issue has been used in other core initiatives.

Please let's keep this issue a low-noise place.

OK. So where shall we have discussions about the details? If we can write that in this issue then anyone who wants more detail knows where to look.

In an earlier revision → of the issue summary, there was the following bullet point:

• Decide on an approach on how mails are going to be built.

Let's turn that bullet point into an issue.

Good idea. I created 🌱 Requirements and strategy for Core Mailer Active .

The goal of this issue is to create specific and clearly defined issues that have majority/consensus support from the core group working on this area. Those issues can then be added to the road-map and assigned to individuals to work on.

I propose that all the other issues be postponed on this one. We don't have to actually set them to postponed, we just wouldn't work on them until the requirements/strategy discussion group has agreed that they are the right direction. Otherwise we risk having conflicts with different people heading in different directions.

This doesn't have to be a heavy/slow process. For example on 📌 [PP-1] Add a way to capture mails sent through the mailer.transport service during tests Postponed I have just one question, as per my comment #16, which could be resolved in 5 minutes.