Problem/Motivation

The future of this project depends on what happens with the Drupal Core mailer - currently it is "maintenance fixes only" until we get some clarity. Some key issues would create an API that this module can use:
#3380041: Create a new email interface that decorates symfony
#3530860: Create a new mailer service to wrap symfony mailer
#3530810: Events/callbacks for new mailer service

Key functions/features are

  1. Get/set Twig variables and get/set the unrendered body, so that the body can be edited as a twig template
  2. 4 phases, and in between them the automatic switching then rendering
  3. Ability to get/set parameters
  4. Convenient and secure attachment handling

Other convenience features

  1. Use other types, especially User entity as if
  2. Automatically set langcode based on 'To' address

I (AdamPS) commented in favour of these issues, but with little effect. Feel free to add your own comment on the issues or chat to the Core maintainers if you feel the issues would be useful.

Proposed resolution

The possible futures are all based on v2.x of this project. It has 4 modules, which I refer to below with the text inside code tags.

Widest usage

If we get the API we would like then the future looks like this: mailer_policy and mailer_transport continue as UIs that work natively over Core, and they each move to their own project with the same name (placeholders exists). These UIs apply to all mails sent. The other 2 modules are no longer needed. However it's not clear that the Core developers wish to go in this direction.

Specialist usage

If Core doesn't provide a useful API, then symfony_mailer could continue as an opt-in Mailer+ framework for building/sending email. mailer_policy would only work for projects that are using the framework. mailer_transport could still configure a default transport that applied to all projects even if not using the framework. We could potentially reimplement mailer_override to swap the Core implementations such as MailHandler to the ones in this project.

Tailing off usage

If few projects opt-in to the previous outcome and few developers continued to support this module then it might hardly be worth continuing the project. It could become abandoned once the old mail framework is removed from Core.

Previous version of Problem/Motivation

Thanks for building and maintaining this module, it works really well!

I saw a note on the project page today, that the module will be discontinued, but luckily in the future, when D11 goes EOL, which could be in 2028, judging from https://www.drupal.org/about/core/policies/core-release-cycles/release-p....

D11

I wondered when this was decided, and had to look into the history to check when the note was added, and it looks like 27 Aug 2025. Perhaps the date could be added before the first sentence, something like this?

27 Aug 2025: I have stopped developing this module [...]

Also, if there is a relevant Drupal core issue where this conclusion was reached, could a link be added? If no such issue exist, of course don't add a link :)

Also, should users steer clear of version 2, or will development continue on that branch as well?

Steps to reproduce

See the note on the front page, and wonder when it was added.
Wonder if version 2 will ever become relevant, or not.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

ressa created an issue. See original summary.

svendecabooter’s picture

svendecabooter
he/him
Primary language Dutch
Location Gent
commented

Would also like some clarification on this.

weseze’s picture

weseze commented

This is the issue where the core mail system is being worked on: https://www.drupal.org/project/drupal/issues/3523592

ressa’s picture

ressa
he/him
commented
Related issues: +#3523592: Mailer module roadmap: the path to beta and stable

Thanks @weseze! Adding as reference, to connect the issues. Still, it would be great to hear from the maintainer @adamps as well.

mlncn’s picture

mlncn commented

Based on reading #3534136: Requirements and strategy for Core Mailer there was disagreement in the architecture for the idea of a core, Symfony-based mailer between adamps and the other person mostly active in the core queue for this, znerol, and as a result adamps stepped away from the core plan and further developing this module.

I'm having trouble following all the related core issues, but they do seem to be continuing to progress somewhat since the late August split and still seem hoping to have an experimental core module by Drupal 11.3.

Remains to be seen if come Drupal 12 time the 46,000+ sites using this module will be most in need of documentation for switching to the in-progress proposed core module or somebody to take over maintaining this a while longer.

ressa’s picture

ressa
he/him
commented
Title: Clarify future of module » Clarify future of the Drupal Symfony Mailer Plus (DSM+) module
Category: Feature request » Plan
Related issues: +#3534136: Requirements and strategy for Core Mailer

Thanks for sharing the link to that issue @mlncn, and yes -- the question is for us users -- what to do, eventually? Will someone else take over maintenance of this module, or will there be an upgrade path to a successor? The addition one or more co-maintainers would be reassuring.

Luckily, 2028 is still in the distant future :)

adamps’s picture

adamps commented

I don't have any magic answers.

The Core developer(s) seemed to prefer to invent a new solution, even though a successful one existed in contrib. For sure I spent hours trying to establish a useful discussion, but my comments were mostly ignored. At the time that I left the team there was no sign of any compatibility at all with this module - it was different at every level.

It's not really a matter of anybody else being able take over maintaining this module. The problem is that the whole basis that this module relies on will likely be gone: the old mail interface (used by the legacy support) will be removed and the new one in core will be entirely different from here. Perhaps this module could still exist for any modules that specific choose to use the interfaces from here rather than the new Core ones, but it potentially won't be attractive for modules to do that.

So, you are reliant on what the Core team produce, and whatever new contrib modules someone else writes. Those are the people who might write the upgrade paths. The new contrib modules can probably copy some parts from here, but it's not really any more the same module, so probably best for people to start new ones. In that way I can ensure this module stays stable for those who want it in the current form, whilst leaving the new team free to do whatever they wish on the new start.

I probably will make a stable 2.x release as the branch has many good bug fixes. However it is significantly non-BC, so any code that uses the interfaces from here would need to be updated. Given the dubious future, people may not wish to. However if you don't rely on any code like that and just use this module directly then 2.x could be a better option.

I added a link from the project page to this issue. If you have concerns then I suggest you raise them in the Core issues.

adamps’s picture

adamps commented
Title: Clarify future of the Drupal Symfony Mailer Plus (DSM+) module » Future of the Drupal Symfony Mailer Plus (DSM+) module
Issue summary: View changes
Priority: Normal » Major

I decided to try being a bit more optimistic. See new IS.

ressa’s picture

ressa
he/him
commented

Thank you so much for the updates, it is a relief to hear that there is optimism :)

adamps’s picture

adamps commented
Title: Future of the Drupal Symfony Mailer Plus (DSM+) module » Future of the Mailer Plus (DSM+) module
Issue summary: View changes