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...