Standard-Mailbibliothek
Standard-Mailbibliothek
Da wir ja jetzt die meisten vorausgesetzten Komponenten (Dwoo als Template Engine, Doctrine als Datenbankabstraktion etc.) per Composer laden - was bedeutet, dass sie nicht im modules-Verzeichnis liegen, was wiederum bedeutet, dass wir keine Extra-Module dafür erstellen müssen, was uns wiederum viel Arbeit spart - stellt sich die Frage, welche Mailbibliothek wir standardmäßig nehmen wollen. Bisher haben wir PHPMailer und Swift unterstützt.
https://github.com/PHPMailer/PHPMailer
https://swiftmailer.symfony.com/
Ich persönlich bin da relativ leidenschaftslos, wobei ich Swift tendenziell vorziehen würde. Gibt es bei irgendwem hier Bedenken gegen die eine oder andere? Oder auch umgekehrt, ist jemand glühender Anhänger einer der beiden? Oder gar einer ganz anderen?
https://github.com/PHPMailer/PHPMailer
https://swiftmailer.symfony.com/
Ich persönlich bin da relativ leidenschaftslos, wobei ich Swift tendenziell vorziehen würde. Gibt es bei irgendwem hier Bedenken gegen die eine oder andere? Oder auch umgekehrt, ist jemand glühender Anhänger einer der beiden? Oder gar einer ganz anderen?
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is
- creativecat
- Beiträge: 1435
- Registriert: Mi 6. Feb 2013, 12:41
- Kontaktdaten:
Re: Standard-Mailbibliothek
Ich stehe irgendwie mehr auf Swift. Vielleicht, weil ich beim PHPMailer schon mehr Sicherheitslücken gelesen habe...
Re: Standard-Mailbibliothek
Wir benutzen ja auch schon andere Komponenten aus Symfony, so gesehen ist es auch konsequent, Swift zu verwenden. Immerhin wird PHPMailer nach Jahren des Stillstands jetzt wieder weiter entwickelt, trotzdem habe auch ich bei Swift ein besseres Gefühl. Dem Anwender wird's eh egal sein, denke ich.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is
- creativecat
- Beiträge: 1435
- Registriert: Mi 6. Feb 2013, 12:41
- Kontaktdaten:
Re: Standard-Mailbibliothek
Ich pack mal das Thema wieder aus. Support für Swift ist seit letztem November eingestellt.
Ich hab jetzt noch die letzte Version über den Composer geladen und würde die aktuellste Version für BC 1.5 hochladen. Der Swift-Driver musste auch ein wenig angepasst werden oder hattest du das absichtlich und selbst mit den getInstance() eingebaut?
Das Teil ist dann bis PHP 8.1 kompatibel.
Danach könnte man mal schauen, dass man den Symphony-Mailer einbaut.
Ich hab jetzt noch die letzte Version über den Composer geladen und würde die aktuellste Version für BC 1.5 hochladen. Der Swift-Driver musste auch ein wenig angepasst werden oder hattest du das absichtlich und selbst mit den getInstance() eingebaut?
Das Teil ist dann bis PHP 8.1 kompatibel.
Danach könnte man mal schauen, dass man den Symphony-Mailer einbaut.
- creativecat
- Beiträge: 1435
- Registriert: Mi 6. Feb 2013, 12:41
- Kontaktdaten:
Re: Standard-Mailbibliothek
Ich hab mal die neueste Version von Swift hochgeladen und ein v1.6-Release gemacht.
Der Katalog ist ebenfalls schon angepasst
Allerdings funktioniert die Version nur mit BC1.5, weil ich den Swift-Driver angepasst habe.
Der Katalog ist ebenfalls schon angepasst
Allerdings funktioniert die Version nur mit BC1.5, weil ich den Swift-Driver angepasst habe.
Re: Standard-Mailbibliothek
Erst mal danke, dass Du Dich darum gekümmert hast! Ich hatte vorhin eine Infomail dazu bekommen und war etwas überrascht, dass da stand "letzte Version".
Gibt es einen Nachfolger oder eine andere Alternative zu Swift?
Edit: Klingt für mich etwas oversized. https://symfony.com/doc/current/mailer.html
Edit2: Dem hier könnte man entnehmen, dass ein Switch zurück zum PHPMailer die Alternative wäre.
https://php.libhunt.com/compare-swiftma ... -phpmailer
Wäre ja kein Problem, ich müßte mir nur mal den Treiber angucken, ob der noch paßt.
Gibt es einen Nachfolger oder eine andere Alternative zu Swift?
Edit: Klingt für mich etwas oversized. https://symfony.com/doc/current/mailer.html
Edit2: Dem hier könnte man entnehmen, dass ein Switch zurück zum PHPMailer die Alternative wäre.
https://php.libhunt.com/compare-swiftma ... -phpmailer
Wäre ja kein Problem, ich müßte mir nur mal den Treiber angucken, ob der noch paßt.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is
- creativecat
- Beiträge: 1435
- Registriert: Mi 6. Feb 2013, 12:41
- Kontaktdaten:
Re: Standard-Mailbibliothek
Welche Aussagekraft hat das Codelevel? L4 bei Symphony und "nur" L2 bei PHPMailer?
Ansonsten bin ich bei beiden leidenschaftslos. Hab zwar bisher nur mit SwifMailer gearbeitet, aber beide tun sicher ihren Dienst
Kleiner Vorteil Symphony: Sollten wir doch irgendwann die TemplateEngine wechseln, dann basiert der SwiftMailer ja schon auf einer ziemlich guten Engine... Aber das liegt vermutlich in ziemlich ferner Zukunft, oder?
Ansonsten bin ich bei beiden leidenschaftslos. Hab zwar bisher nur mit SwifMailer gearbeitet, aber beide tun sicher ihren Dienst
Kleiner Vorteil Symphony: Sollten wir doch irgendwann die TemplateEngine wechseln, dann basiert der SwiftMailer ja schon auf einer ziemlich guten Engine... Aber das liegt vermutlich in ziemlich ferner Zukunft, oder?
Re: Standard-Mailbibliothek
Bei der TE bin ich nun wieder schmerzfrei, wir müssen halt "nur" die ganzen Plugins und vermutlich einige Module neu bauen, das muss die neue TE dann unterstützen. Bei meinen Modulen benutze ich inzwischen ja gar keine TE mehr. Weniger Ballast.
Schätze die Level haben was mit der Code-Qualität zu tun, aber da müßte ich auch erst nachlesen.
Es ist ja auch erst mal so, dass Swift vielleicht nicht weiter entwickelt wird, aber auch nicht mit dem EOL von einem Tag auf den anderen nicht mehr funktioniert. Wenn der neue Symfony-Mailer auch als eigenständige Komponente eingesetzt werden kann, können wir den auch gern als Ersatz aufnehmen. Ich hab halt nur den Eindruck, damit schießen wir mit Kanonen auf Spatzen. BC versendet vermutlich zu 99% reinen Text, nicht mal HTML, geschweige denn Anhänge oder sonstigen "Schnickschnack". Aber wenn's halt "state of the art" ist, nehmen wir es eben und gut.
Schätze die Level haben was mit der Code-Qualität zu tun, aber da müßte ich auch erst nachlesen.
Es ist ja auch erst mal so, dass Swift vielleicht nicht weiter entwickelt wird, aber auch nicht mit dem EOL von einem Tag auf den anderen nicht mehr funktioniert. Wenn der neue Symfony-Mailer auch als eigenständige Komponente eingesetzt werden kann, können wir den auch gern als Ersatz aufnehmen. Ich hab halt nur den Eindruck, damit schießen wir mit Kanonen auf Spatzen. BC versendet vermutlich zu 99% reinen Text, nicht mal HTML, geschweige denn Anhänge oder sonstigen "Schnickschnack". Aber wenn's halt "state of the art" ist, nehmen wir es eben und gut.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is
- creativecat
- Beiträge: 1435
- Registriert: Mi 6. Feb 2013, 12:41
- Kontaktdaten:
Re: Standard-Mailbibliothek
Ich schicke grundsätzlich HTML-Emails, weil alle Kunden wollen, dass es toll aussieht
Ich habe auch schon 2 Projekte mit BC umgesetzt, bei denen ich sogar zwingend Anhänge brauche - da werden zB für Veranstaltung QR-Codes verschickt, die als Eintrittskarte gescannt werden können
Aber das alles kann PHPMailer auch, soweit ich das gesehen habe.
Ich habe auch schon 2 Projekte mit BC umgesetzt, bei denen ich sogar zwingend Anhänge brauche - da werden zB für Veranstaltung QR-Codes verschickt, die als Eintrittskarte gescannt werden können
Aber das alles kann PHPMailer auch, soweit ich das gesehen habe.
Re: Standard-Mailbibliothek
Ich schau mir mal den neuen Symfony Mailer an und mach nen Treiber dafür. (Wenn's denn geht.)
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
If it’s not broken, keep fixing it until it is