> 🛠 [**PHP/Tutorials/Symfony Mailer**](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) - ja, das ist zu schwierig für jemanden, der nur „mal“ ein paar Mails senden will. Wir wollen aber best practices und aktuelle Frameworks vorstellen. Wenn es einem Anfänger zu schwierig ist, auch gut! Hm. Sieht nach einem Hut aus, der mir passen könnte (Weil ich mir ggf. auch die Testumgebungen basteln kann). Das alte Login funktioniert auch noch. **Aber!** Es sieht so aus, als müsste der Artikel auch komplett neu strukturiert werden - [schon weil der Symphony Mailer „ein paar Transport-Methoden mehr“ kennt](https://symfony.com/doc/current/mailer.html). Ich frag mal wie Marcus Aurelius, (hilfsweise Mark Aurel oder jede frankophone Person): ***„Was ist es, was das ist?“* Oder: Worüber wäre hier zu schreiben?** - **Sinnhaftigkeit:** Es gibt Fälle, in denen ein simples `mb_send_mail()` klüger ist. - **Generelle Regeln** (Wer bestimmt Empfänger, Versender, Subjekt, Inhalt, Bestätigungsmail - oder besser nicht ...) - **Installationsmethoden** (composer kann nicht jeder ausführen, Installation mit den Mitteln des OS (man schaue z.B. unter Debian mit `apt list '*symfony*mail*'` nach…), von github (https://github.com/symfony/mailer) oder ggf. vom Hoster (da sollte bei einer Handvoll der „Großen“ nachgeschaut werden) **und Folgen hinsichtlich notwendiger Updates.** - Bei den **Transportmethoden** muss wohl unbedingt auf die Thematik der Sicherheit der Zugangsdaten eingegangen werden. - Und ein wenig darauf, **wie SMTP eigentlich funktioniert** - und was in welchem Fall noch so alles getan werden muss, damit Mails ankommen (DNS, Firewall, Smarthost) - und wer das tut oder tun muss (eigener Server?) **Wenn (*Falls*) im Artikel (*doch*) eigene Beispiele gezeigt werden sollen stellt sich die Frage, wie weit das gehen soll:** - Mail mit alternativen HTML/Textpart, - Zusätzlich mit Anhängen, - Nutzung verschiedener Transportmethoden, - ? Wie auch immer: Wenn Beispiele gezeigt werden sollen muss das bestehende Beispiel (wohl) in einen HTML-Part und einen PHP-Part getrennt werden. Sonst wird der eh schon umfängliche Artikel durch Redundanzen aufgebläht und notlos unübersichtlich. **Das alles ist *„ziemlich viel Holz“* für *eine* Seite!** denn es artet schon im Hinblick auf die vielen Fallunterscheidungen zu einem ganzen Buch aus und ein solches auf einer Seite unterzubringen dürfte nicht nur für Autoren schwierig werden sondern im Ergebnis auch viele Leser überfordern. Das führt direkt zu der Frage, [ob statt eigener Beispiele nicht besser direkt auf jene in der Dokumentation verwiesen werden sollte](https://symfony.com/doc/current/mailer.html) = <https://symfony.com/doc/7.0/mailer.html>. Die sieht nämlich ziemlich stabil aus (ist „versioniert“) - was, wenn man es richtig macht, eine Überarbeitung ziemlich einfach aussehen lässt.

> 🛠 [**PHP/Tutorials/Symfony Mailer**](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) - ja, das ist zu schwierig für jemanden, der nur „mal“ ein paar Mails senden will. Wir wollen aber best practices und aktuelle Frameworks vorstellen. Wenn es einem Anfänger zu schwierig ist, auch gut! Hm. Sieht nach einem Hut aus, der mir passen könnte (Weil ich mir ggf. auch die Testumgebungen basteln kann). Das alte Login funktioniert auch noch. **Aber!** Es sieht so aus, als müsste der Artikel auch komplett neu strukturiert werden - [schon weil der Symphony Mailer „ein paar Transport-Methoden mehr“ kennt](https://symfony.com/doc/current/mailer.html). Ich frag mal wie Marcus Aurelius, (hilfsweise Mark Aurel oder jede frankophone Person): ***„Was ist es, was das ist?“* Oder: Worüber wäre hier zu schreiben?** - **Sinnhaftigkeit:** Es gibt Fälle, in denen ein simples `mb_send_mail()` klüger ist. - **Generelle Regeln** (Wer bestimmt Empfänger, Versender, Subjekt, Inhalt, Bestätigungsmail - oder besser nicht ...) - **Installationsmethoden** (composer kann nicht jeder ausführen, Installation mit den Mitteln des OS (man schaue z.B. unter Debian mit `apt list '*symfony*mail*'` nach…), von github (https://github.com/symfony/mailer) oder ggf. vom Hoster (da sollte bei einer Handvoll der „Großen“ nachgeschaut werden) **und Folgen hinsichtlich notwendiger Updates.** - Bei den **Transportmethoden** muss wohl unbedingt auf die Thematik der Sicherheit der Zugangsdaten eingegangen werden. - Und ein wenig darauf, **wie SMTP eigentlich funktioniert** - und was in welchem Fall noch so alles getan werden muss, damit Mails ankommen (DNS, Firewall, Smarthost) - und wer das tut oder tun muss (eigener Server?) **Wenn (*Falls*) im Artikel eigene Beispiele gezeigt werden sollen stellt sich die Frage, wie weit das gehen soll:** - Mail mit alternativen HTML/Textpart, - Zusätzlich mit Anhängen, - Nutzung verschiedener Transportmethoden, - ? Wie auch immer: Wenn Beispiele gezeigt werden sollen muss das bestehende Beispiel (wohl) in einen HTML-Part und einen PHP-Part getrennt werden. Sonst wird der eh schon umfängliche Artikel durch Redundanzen aufgebläht und notlos unübersichtlich. **Das alles ist *„ziemlich viel Holz“* für *eine* Seite!** denn es artet schon im Hinblick auf die vielen Fallunterscheidungen zu einem ganzen Buch aus und ein solches auf einer Seite unterzubringen dürfte nicht nur für Autoren schwierig werden sondern im Ergebnis auch viele Leser überfordern. Das führt direkt zu der Frage, [ob statt eigener Beispiele nicht besser direkt auf jene in der Dokumentation verwiesen werden sollte](https://symfony.com/doc/current/mailer.html) = <https://symfony.com/doc/7.0/mailer.html>. Die sieht nämlich ziemlich stabil aus (ist „versioniert“) - was, wenn man es richtig macht, eine Überarbeitung ziemlich einfach aussehen lässt.

> 🛠 [**PHP/Tutorials/Symfony Mailer**](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) - ja, das ist zu schwierig für jemanden, der nur „mal“ ein paar Mails senden will. Wir wollen aber best practices und aktuelle Frameworks vorstellen. Wenn es einem Anfänger zu schwierig ist, auch gut! Hm. Sieht nach einem Hut aus, der mir passen könnte (Weil ich mir ggf. auch die Testumgebungen basteln kann). Das alte Login funktioniert auch noch. **Aber!** Es sieht so aus, als müsste der Artikel auch komplett neu strukturiert werden - [schon weil der Symphony Mailer „ein paar Transport-Methoden mehr“ kennt](https://symfony.com/doc/current/mailer.html). Ich frag mal wie Marcus Aurelius, (hilfsweise Mark Aurel oder jede frankophone Person): ***„Was ist es, was das ist?“* Oder: Worüber wäre hier zu schreiben?** - **Sinnhaftigkeit** (Es gibt Fälle, in denen ein simples `mb_send_mail()` klüger ist. - **Generelle Regeln** (Wer bestimmt Empfänger, Versender, Subjekt, Inhalt, Bestätigungsmail - oder besser nicht ...) - **Installationsmethoden** (composer kann nicht jeder ausführen, Installation mit den Mitteln des OS (man schaue z.B. unter Debian mit `apt list '*symfony*mail*'` nach…), von github (https://github.com/symfony/mailer) oder ggf. vom Hoster (da sollte bei einer Handvoll der „Großen“ nachgeschaut werden) **und Folgen hinsichtlich notwendiger Updates.** - Bei den **Transportmethoden** muss wohl unbedingt auf die Thematik der Sicherheit der Zugangsdaten eingegangen werden. - Und ein wenig darauf, **wie SMTP eigentlich funktioniert** - und was in welchem Fall noch so alles getan werden muss, damit Mails ankommen (DNS, Firewall, Smarthost) - und wer das tut oder tun muss (eigener Server?) **Wenn (*Falls*) im Artikel eigene Beispiele gezeigt werden sollen stellt sich die Frage, wie weit das gehen soll:** - Mail mit alternativen HTML/Textpart, - Zusätzlich mit Anhängen, - Nutzung verschiedener Transportmethoden, - ? Wie auch immer: Wenn Beispiele gezeigt werden sollen muss das bestehende Beispiel (wohl) in einen HTML-Part und einen PHP-Part getrennt werden. Sonst wird der eh schon umfängliche Artikel durch Redundanzen aufgebläht und notlos unübersichtlich. **Das alles ist *„ziemlich viel Holz“* für *eine* Seite!** denn es artet schon im Hinblick auf die vielen Fallunterscheidungen zu einem ganzen Buch aus und ein solches auf einer Seite unterzubringen dürfte nicht nur für Autoren schwierig werden sondern im Ergebnis auch viele Leser überfordern. Das führt direkt zu der Frage, [ob statt eigener Beispiele nicht besser direkt auf jene in der Dokumentation verwiesen werden sollte](https://symfony.com/doc/current/mailer.html) = <https://symfony.com/doc/7.0/mailer.html>. Die sieht nämlich ziemlich stabil aus (ist „versioniert“) - was, wenn man es richtig macht, eine Überarbeitung ziemlich einfach aussehen lässt.

> 🛠 [**PHP/Tutorials/Symfony Mailer**](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) - ja, das ist zu schwierig für jemanden, der nur „mal“ ein paar Mails senden will. Wir wollen aber best practices und aktuelle Frameworks vorstellen. Wenn es einem Anfänger zu schwierig ist, auch gut! Hm. Sieht nach einem Hut aus, der mir passen könnte (Weil ich mir ggf. auch die Testumgebungen basteln kann). Das alte Login funktioniert auch noch. **Aber!** Es sieht so aus, als müsste der Artikel auch komplett neu strukturiert werden - [schon weil der Symphony Mailer „ein paar Transport-Methoden mehr“ kennt](https://symfony.com/doc/current/mailer.html). Ich frag mal wie Marcus Aurelius, (hilfsweise Mark Aurel oder jede Frankophone Person): ***„Was ist es, was das ist?“* Oder: Worüber wäre hier zu schreiben?** - **Sinnhaftigkeit** (Es gibt Fälle, in denen ein simples `mb_send_mail()` klüger ist. - **Generelle Regeln** (Wer bestimmt Empfänger, Versender, Subjekt, Inhalt, Bestätigungsmail - oder besser nicht ...) - **Installationsmethoden** (composer kann nicht jeder ausführen, Installation mit den Mitteln des OS (man schaue z.B. unter Debian mit `apt list '*symfony*mail*'` nach…), von github (https://github.com/symfony/mailer) oder ggf. vom Hoster (da sollte bei einer Handvoll der „Großen“ nachgeschaut werden) **und Folgen hinsichtlich notwendiger Updates.** - Bei den **Transportmethoden** muss wohl unbedingt auf die Thematik der Sicherheit der Zugangsdaten eingegangen werden. - Und ein wenig darauf, **wie SMTP eigentlich funktioniert** - und was in welchem Fall noch so alles getan werden muss, damit Mails ankommen (DNS, Firewall, Smarthost) - und wer das tut oder tun muss (eigener Server?) **Wenn (*Falls*) im Artikel eigene Beispiele gezeigt werden sollen stellt sich die Frage, wie weit das gehen soll:** - Mail mit alternativen HTML/Textpart, - Zusätzlich mit Anhängen, - Nutzung verschiedener Transportmethoden, - ? Wie auch immer: Wenn Beispiele gezeigt werden sollen muss das bestehende Beispiel (wohl) in einen HTML-Part und einen PHP-Part getrennt werden. Sonst wird der eh schon umfängliche Artikel durch Redundanzen aufgebläht und notlos unübersichtlich. **Das alles ist *„ziemlich viel Holz“* für *eine* Seite!** denn es artet schon im Hinblick auf die vielen Fallunterscheidungen zu einem ganzen Buch aus und ein solches auf einer Seite unterzubringen dürfte nicht nur für Autoren schwierig werden sondern im Ergebnis auch viele Leser überfordern. Das führt direkt zu der Frage, [ob statt eigener Beispiele nicht besser direkt auf jene in der Dokumentation verwiesen werden sollte](https://symfony.com/doc/current/mailer.html) = <https://symfony.com/doc/7.0/mailer.html>. Die sieht nämlich ziemlich stabil aus (ist „versioniert“) - was, wenn man es richtig macht, eine Überarbeitung ziemlich einfach aussehen lässt.