Wrong return value for MailManagerReplacement::mail()

Thanks for the report. If you can find an easy fix then I would accept it.

MailManagerReplacement is not necessarily going to copy the exact implementation details of MailManager. Symfony provides its own spooling capability, so sites using this module are probably better using that.

I don't think the return value is an implementation detail ;-)

The Views Send module tries to support multiple MIME enabling modules, and it has been a struggle since they tend to not follow MailManagerInterface closely. Since this module has this legacy support, I hoped to not write custom code.

I'll see if there is an easy fix.

> I don't think the return value is an implementation detail ;-)
Yes but you already said yourself "It isn't 100% clear that this is the formatted / "as sent" message". You made your point by looking at the implementation of MailManager::doMail().

I was trying to be open about the fact that the documentation isn't sufficiently clear - and tried to support my claim with the core implementation of the interface. All other modules have I testet (at some point) - mailgun, mailchimp_transactional, mimemail, phpmailer_smtp, sendgrid_integration (and some older D7 modules) interpreted it to be the formatted message too.

I have tried earlier to get the docs clearer, but failed to get any interest. Or, people are busy :-)

Well I already said I'm willing to fix it if it's easy😃. It's possible that Symfony Mailer library doesn't actually make the information you would like available - this is basically what I'm trying to get at by saying "implementation detail".

The other modules you are referring to are all @Mail plug-ins, so naturally they will provide this information, they implement a completely different interface.

What I'm saying is that in my view the whole mail manager replacement concept is best-effort to aid transition to the new API. There is another module Drupal Symfony Mailer Lite for people who want exact BC. However eventually the old API is likely to removed from Core.

The amount of my energy and free time that I wish to allocate this issue is limited, and at the moment you are using a lot of it up arguing with me😃.

I'd like to add a more positive comment.

support multiple MIME enabling modules, and it has been a struggle since they tend to not follow MailManagerInterface closely

IMHO it's important to see that MailManagerInterface does not officially support MIME - it's an ancient API from the days of plain text mails over sendmail. Also it doesn't provide a clear definition of the distinction between compose and send. Sweiftmailer seems to split code fairly arbitrarily between the format and send functions.

AFAICS this and 🐛 MailManagerReplacement::mail() doesn't always compose Active are related to a similar aim: using the $send flag to implement spooling over MailManagerReplacement. The $send flag was awkward to handle in this case as it didn't fit well with the symfony library. Perhaps it's never going to be perfect, and it's also perhaps not a widely needed case, because...

Symfony Mailer library already supports spooling. So anyone who wants to use spooling with DSM should do that. There seems little point in putting effort into anything else. This means that Queue Mail is perhaps no longer needed with DSM. And Views Send could entirely skip everything related to spooling if DSM is also installed.

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. I also have little time to waste, you know.

IMHO it's better to remove MailManagerReplacement as I think it gives false promises. You are of course technically correct - I was mixing to interfaces.

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.