Resolve potential namespace conflict with contrib mailer module

Tagging with 11.3 release priority. This needs to be resolved before release.

The contrib module is currently not compatible with D11 and also has only 34 sites that report using it.

When the mailer ceases to be experimental, do we still need a Core module? If so, then I feel we should keep the name "mailer". If this is only a temporary module, then one option is to give it a name that indicates the temporary status.

I tried what happens on a site where the contrib mailer module is enabled during an upgrade. The contrib mailer module doesn't have a Drupal 11 release ready, so I had to patch it.

This is what I did:

Install Drupal 11 and drush:

composer create-project --no-interaction "drupal/recommended-project:^11" mailer-contrib-test
cd mailer-contrib-test
composer require -W drush/drush

Install the contrib mailer and patch for D11 compatibility:

composer require mglaman/composer-drupal-lenient
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/mailer"]'
composer require 'drupal/mailer:^2.0@beta'
sed -i 's/^core_version_requirement.*/core_version_requirement: ^10 | ^11/' web/modules/contrib/mailer/mailer.info.yml web/modules/contrib/mailer/modules/mailer_example/mailer_example.info.yml

Run a database and install the site:

podman run -d --rm --network=host --name=drupal_memory --tmpfs=/var/lib/pg/data -e PGDATA=/var/lib/pg/data -e POSTGRES_PASSWORD=postgres -e POSTGRES_USER=postgres -e POSTGRES_DB=drupal docker.io/library/postgres:16
./vendor/bin/drush site-install --db-url=pgsql://postgres:postgres@localhost/drupal --no-interaction

Setup mailpit as sendmail binary:

chmod u=rwX,go=rX web/sites/default web/sites/default/*
echo "sendmail_path = ${HOME}/bin/mailpit sendmail" > web/sites/default/php.ini
export PHPRC="${PWD}/web/sites/default"

Enable the contrib mailer and the example module, generate login link, run the built-in webserver:

./vendor/bin/drush en mailer mailer_example
./vendor/bin/drush uli --no-browser --uri=http://localhost:8888
http://localhost:8888/user/reset/1/1755891039/btjHfkrOCd7x1nKu8KtRJ8DmHoNCpwxW548Ul0HLyJk/login
./vendor/bin/drush rs

Open the test page and mailpit in a second tab and confirm that mailer test mail gets delivered:

xdg-open 'http://localhost:8888/admin/config/system/mailer/example'
xdg-open 'http://localhost:8025/'

Upgrade the site to 11.x-dev:

composer require -W "drupal/core-recommended:^11.x-dev" "drupal/core-recipe-unpack:^11.x-dev" "drupal/core-project-message:^11.x-dev" "drupal/core-composer-scaffold:^11.x-dev" "drupal/core:11.x-dev"
./vendor/bin/drush updb
./vendor/bin/drush cr

Confirm that now there are two mailer modules in the filesystem:

find . -name mailer

Open the test form and do the test again.

Interestingly in my case after all these steps, things are still working as before. So, it looks like the contrib mailer module wins the race for the \Drupal\mailer namespace.

Maintainer of the mailer contrib module here.
The D11 version of this module is being worked on and will be available in the future.

Move the module
I am willing to move the module and rename, document, ... if the decision is made to keep the name of the core project.

Alter the core version
I prefer this option as this will be less work / effort for all people impacted.
I could move the project, and document this, but it would always be a pain for users of the contrib mailer module while updating existing websites.
As this is an API module the needed changes would involve altering the use statements of all mailer plugins in all projects using this module.

As potential errors would occur when updating Drupal Core and not mailer we can't expect people to have read the documentation / release notes of the mailer module. It's an option to place a note in the core release notes, but that would be weird for a module with only 34 reported installs.

Do nothing
If the plan is to only keep the core module in experimental phase, and then move the code to the core framework, this could potentially never impact any website. If the users of the contrib mailer module keep the experimental core module disabled and do not use the new functionality before frame work inclusion.

Thanks @stijn.blomme for your thoughts.

Do nothing

If the plan is to only keep the core module in experimental phase, and then move the code to the core framework, this could potentially never impact any website. If the users of the contrib mailer module keep the experimental core module disabled and do not use the new functionality before frame work inclusion.

This is more or less what I tested in #4. The important thing to realize here is that users of the contrib mailer module do not have the choice to enable or disable the experimental core module. Modules need to have a unique name. And it looks like a module from contrib seems to override a module in core with the same name.

But honestly, as a site owner I wouldn't want to risk having two modules with the same name in my source tree. The findings in #4 should be treated as anecdotal. This certainly doesn't proof that two modules with the same name will coexist peacefully over the lifetime of a site.

As potential errors would occur when updating Drupal Core and not mailer we can't expect people to have read the documentation / release notes of the mailer module.

The contrib mailer module doesn't have a D11 compatible release. So sites using the contrib mailer wouldn't be able to update to Drupal 11 anyway yet. The experimental core mailer module will not be backported to any Drupal 10 release.

Opened an MR that renames mailer into mailer_experiment. In my eyes that name (a) underlines that the module will go away when the experiment is over and (b) it works as a feature flag.

The CR → needs minor updates when this gets committed.

I was wondering if we sould also alter the module name? This is still 'Mailer' It might be clearer if the name is Mailer Symfony

Services are not yet renamed (mailer_symfony.services.yml)
- 30: Drupal\Core\Mailer\Transport\SendmailCommandValidationTransportFactory -> Drupal\Core\mailer_symfony\Transport\SendmailCommandValidationTransportFactory
- 38: Drupal\Core\Mailer\TransportServiceFactory -> Drupal\Core\mailer_symfony\TransportServiceFactory
- 41: Drupal\Core\Mailer\TransportServiceFactoryInterface -> Drupal\Core\mailer_symfony\TransportServiceFactoryInterface

Mailerhooks:
25: The Mailer module provides an experimental -> The Mailer Symfony module
25: nline documentation for the Mailer module< -> Mailer Symfony module
26: Should the link change?

src/Kernel/TransportTest.php
30: If we alter the name, these comments should mention mailer_symfony

I think we explicitly don't want to do use Symfony there, if they didn't like Symfony Mailer in contrib, then they also wont' like "Mailer Symfony". It's the underlying system, but the current direction is that we will provide our own API on top of it, just like Drupal as a whole is built on top of some Symfony components.

The name is much easier to change than the machine name, so there I think we could use Experimental, so I'd go with "Experimental Mail(er) API". We can change once it's no longer experimental.

We are also not renaming the Core component, there is no conflict here and things like "mailer DSN" is a concept of the Symfony Mailer component, not the module name.

My intention was to only change the module namespace. But of course, if there are two modules available with the same human readable name, that would be confusing.

Without rename:

Experimental Mailer:

Core Mailer Preview:

What about Core Mailer Preview?

What about just mail for the core module?

https://www.drupal.org/project/mail → exists but seems to be abandoned, we could ask the maintainers whether we could take over the namespace?

I do not think that mail is abandoned. At least, the mail.info.yml declares compatibility with Drupal 10.

https://git.drupalcode.org/project/mail/-/blob/8.x-1.x/mail.info.yml?ref...

The only commits since 2017 are Drupal 9 and 10 compatibility fixes, there are no published compatible releases and it is "seeking new maintainers", next week I will contact the maintainers and ask.

Mail module is my project for a new config-based mail system in core.
I've not managed to get any traction for getting it into core, but it's not abandoned.

https://www.drupal.org/project/email → is a D7 only module that was merged into core for D8.

Trying to find something short and simple here, because I think mailer_symfony is both long-winded and could easily be confused with symfony_mailer.

@longwave in the meeting at 03/09/25 mails or email were also suggested.
https://www.drupal.org/project/drupal/issues/3544898#comment-16256380 📌 [meeting] 2025-09-03 core mailer beta planning Active

Mails is still available, emails is indeed an unsupported d7 module.
mailer_symfony was selected as the module will provide a wrapper around the symfony_mailer component.

mailer module in core is just about sending emails, not at all about configuring / translating / altering / etc?

If so, its name should reflect that it's low-level.

What about using symfony_mailer, since the project page for that says it'll be retired after D11?

• We are trying to avoid a namespace conflict with an existing contrib module. Claiming the namespace of another existing contrib module doesn't seem to make much sense.
• The core mailer module isn't supposed to stay in core. It is a temporary container for a bunch of service definitions. The service implementations themselves are added to Drupal\Core\Mailer namespace directly. When enough of the implementation is stable, the service definitions will be moved to core.services.yml and the core mailer module goes straight from experimental to deprecated.

So, I'd suggest to either agree on a namespace which is available or just not do anything at all.