MailManagerReplacement::mail() doesn't always compose

Created on 17 October 2023, about 1 year ago
Updated 21 November 2023, about 1 year ago

Problem/Motivation

According to the core documentation MailManagerInterface::mail() "Composes and optionally sends an email message". This is the actually behavior too. It seems that MailManagerReplacement::mail() only composes the mail if it is actually sent.

Steps to reproduce

Call mail() with the $send parameter set to false. Observe that the message isn't composed - for example headers are missing. This is quite obvious since all formatting / processing of the mail happens in Mailer::doSend()

Proposed resolution

Make it possible to just compose the message as the interface states.

The Mail System modules handled this earlier by splitting formatting and sending. I understand that this split isn't obvious for this module as it handles both formatting and sending.

Remaining tasks

πŸ› Bug report
Status

Active

Version

1.4

Component

Code

Created by

πŸ‡³πŸ‡΄Norway hansfn

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

Comments & Activities

  • Issue created by @hansfn
  • πŸ‡¬πŸ‡§United Kingdom adamps

    You are right.

    I suggest the fix is something like this:

    if (!$send) {
      $email->addProcessor(function () { 
        throw new SkipMailException('Sending disabled'); 
      }, PHASE_POST_RENDER, 1000);
    }
    
    
  • πŸ‡³πŸ‡΄Norway hansfn

    Thx for the quick reply. I'll test and come back to you later this week - if confirmation is needed ;-)

  • πŸ‡³πŸ‡΄Norway hansfn

    I have been playing a little bit with $email->addProcessor, but I don't seem to be able to add / call it at a valid phase - should be init (0) and I'm only able to do it the build phase (1) it seems. Could you give me some more pointers?

  • Assigned to adamps
  • πŸ‡¬πŸ‡§United Kingdom adamps

    Yes I see what you mean. I don't have an immediate answer, I'll think about itπŸ˜ƒ

  • Status changed to Closed: won't fix about 1 year ago
  • πŸ‡³πŸ‡΄Norway hansfn

    Thx for you time and effort. It seems the way forward is to avoid using MailManager (for Symfony Mailer) and rather implement support for Symfony Mailer using the new API.

  • Status changed to Active about 1 year ago
  • πŸ‡¬πŸ‡§United Kingdom adamps

    I'm sorry I wish I'd been more positive. It's quite challenging maintaining this module with so many people having different requests, and sometimes I get stressed.

    MailManagerReplacement is not perfect and I never intended or expected it to be perfect, but still it's being used successfully on 1000s of sites. In fact it's an extremely important part of this module, and no way can we remove it.

    I found a challenge in the dialogue here that seemed to be insisting and expecting a level of perfection that in fact I never promised. As I said before, I'm willing to fix it if it's easy. If not then we have other options.

  • πŸ‡¬πŸ‡§United Kingdom adamps
Production build 0.71.5 2024