Contrib.social

MailManagerReplacenent should override getInstance()

Open on Drupal.org →
Created on 21 May 2024, 10 months ago

Problem/Motivation

Drupal\symfony_mailer\MailManagerReplacement extends the core MailManager implementation but it only overrides the implementation of the mail() function, but not of getInstance() which retrieves the "instance of the mail plugin to use for a given message ID". It does it by reading the system.mail configuration which it not used by Symfony Mailer anymore. And in some cases the configuration might not even exist. This can lead to strange errors.

Therefore, the MailManagerReplacement should override getInstance() and return the correct instance which must be an implementation of Drupal\Core\Mail\MailInterface.

Steps to reproduce

Install and configure Symfony Mailer and Webform (>= 6.2).
Create a webform with an email handler.
Test sending the email, it should be created using the Drupal\symfony_mailer\Plugin\EmailBuilder\LegacyEmailBuilder.
Install the Webprofiler module and enable it's mail toolbat item to track sent emails.

in my case this leads to the following error(s) logged:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. Valid plugin IDs for Drupal\symfony_mailer\MailManagerReplacement are: devel_mail_log, webform_php_mail, symfony_mailer, php_mail, test_mail_collector in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (Zeile 53 in web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Drupal\Core\Entity\EntityStorageException: The "" plugin does not exist. Valid plugin IDs for Drupal\symfony_mailer\MailManagerReplacement are: devel_mail_log, webform_php_mail, symfony_mailer, php_mail, test_mail_collector in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (Zeile 817 in web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Uncaught PHP Exception Drupal\Core\Entity\EntityStorageException: "The "" plugin does not exist. Valid plugin IDs for Drupal\symfony_mailer\MailManagerReplacement are: devel_mail_log, webform_php_mail, symfony_mailer, php_mail, test_mail_collector" at SqlContentEntityStorage.php line 817

All three errors contain the same error message but don't give any clue where exactly or why it has been caused. I found this cause by extensive debugging only.

🐛 Bug report
Status

Active

Version

1.4

Component

Code

Created by

🇦🇹Austria mvonfrie

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @mvonfrie
  • Comment 9 months ago →
    🇦🇹Austria mvonfrie

    Typo in issue title corrected.

  • Status changed to Postponed: needs info about 1 month ago
  • Comment about 1 month ago →
    🇬🇧United Kingdom adamps

    I'm confused. It seems that you have a site without configuration for mail plugin instances and you are calling getInstance() then complaining that it fails😃. I suggest you should either configure the instances or prevent the call.

    Therefore, the MailManagerReplacement should override getInstance() and return the correct instance which must be an implementation of Drupal\Core\Mail\MailInterface.

    But how could we do that? This module has no information about what would be a correct instance of a mail plugin.

  • Comment 20 days ago →
    🇦🇹Austria mvonfrie

    It is more a problem with Webform module doing it's own mail handling and it doesn't know about symfony_mailer. So maybe it is more a problem of Webform than Symfony Mailer. But Symfony Mailer should handle this case, maybe defaulting to symfony_mailer because the core implementation of course doesn't know about Symfony Mailer.

  • Comment 6 days ago →
    🇬🇧United Kingdom adamps

    Symfony mailer doesn't have any implementation Drupal\Core\Mail\MailInterface, and has no reason to create one. What would such an implementation even do? I feel this is a won't fix, or perhaps set to Webform.

    Either you need to create system.mail configuration on your site, or persuade the Webform maintainers to change their module to work without this configuration. It's not really related to this module, which neither requires nor creates the legacy config.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024