search

neos / swiftmailer

A Flow package for easy use of SwiftMailer
MIT License
14 stars 18 forks source link

Swiftmailer is outdated, switch to symfony mailer #22

Open Benjamin-K opened 2 years ago

Benjamin-K commented 2 years ago

As of November 2021, the swiftmailer/swiftmailer package has stopped being maintained and has moved to symfony/mailer. We should reflect that for Neos, too.

albe commented 2 years ago

Some things were discussed in slack a few moments ago:

Søren Malling 12:20 @kopfaufholz https://neos-project.slack.com/archives/C050KKBEB/p1631611348016400

SwiftMailer is going EOL and replaced by Symfony Mailer https://symfony.com/blog/the-end-of-swiftmailer - is it time for a new Neos package as replacement for Neos.SwiftMailer? Thread in flow-core-dev | Sep 14th, 2021 | View message

I’ve checked it out and found some issues with PSR factories not being found when I wanted to use the mailgun adaptor Symfony mailer had a “hidden dependency” on a symfony http client library (edited)

Christian Müller 12:22 we might need a wrapper just to make configuration and injection sensible? which is about what the swiftmailer package does as well

Søren Malling 12:22 https://github.com/symfony/symfony/issues/44124

44124 Mailers should not depend on Symfony's HttpClientInterface

Christian Müller 12:22 NARF https://github.com/PHPMailer/PHPMailer maybe ?

Søren Malling 12:25 I’m using mailguns library directly and injecting the urifactory and httpclient I need (PSR supported)

Martin Ficzel 12:35 That adapter could help https://github.com/SAM-IT/symfony-http-psr18 SAM-IT/symfony-http-psr18 An adapter that wraps a PSR-18 Http Client and provides a Symfony Http Client

Alexander Berl 12:37 So we create a lasagna of adapter layers, because they don't want the "lasagna" of PSR interfaces? Not so fond of it

Christian Müller 13:00 or we use phpmailer

Søren Malling 13:04 @kopfaufholz That’s another dependency, created out of need - I will vote against adding that (edited) Or we deprecate the SwiftMailer package and do not provide a substitute

Karsten Dambekalns 13:07 I read up on Symfony Mailer and tried to understand what we'd need to use it briefly. Admittedly I didn't consider it extremely important at that point, because… well. SwiftMailer still works :sunglasses: But I remember thinking ugh a few times back then.

nezaniel commented 2 years ago

Do we have any meaningful contact to the Symfony community that might help resolving this? Them using hidden dependencies seems to clearly contradict their component architecture approach (as the mailer is declared such a component), at least someone over there should be sympathetic to our point of view

nezaniel commented 2 years ago

In the meantime, would it make sense to declare symfony mailers that conflict with our PSR implementation as, well, conflicting via composer? I mean it's not as if SwiftMailer supports those anyway, does it?