Symfony Mailer

[Raketenwilli]

🛠 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.

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/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.

[Matthias Scharwies]

Servus!

🛠 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.

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.

Ja, darum geht es!

Viele Fragende wissen vermeintlich, was sie wollen. Ob das das ist, was sie können oder gar wirklich brauchen, ist oft noch nicht klar.

• Generelle Regeln (Wer bestimmt Empfänger, Versender, Subjekt, Inhalt, Bestätigungsmail - oder besser nicht ...)

Ja.

• 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,
• ?

Das ist genau die Falle, in die wir manchmal tappen. Nutzer wollen etwas, wissen nicht wie und kopieren dann etwas zusammen. Da sind einzelne Snippets besser als eine komplettlösung, die mit C&P zur unbedachten Nutzung einlädt.

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!

Und das ist eben die Kunst:

Ein Thema

drei Unterpunkte

Grundwissen festlegen und dann auf die entsprechenden Anfänger-Tutorial verweisen

rechtzeitig aufhören und in einem Ausblick auf weitere Möglichkeiten verweisen.

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/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.

Das wäre auch gut.

Vielen Dank im Voraus!

Herzliche Grüße

Matthias Scharwies

[Raketenwilli]

Ich hab den Artikel gerade in Arbeit.

Da es notwendig ist, diesen komplett neu zu schreiben und weil ich wenig Erfahrung mit der Syntax des Wikis und noch weniger Wissen über die von den Autoren geforderte Struktur und Herangehensweise habe bitte ich einfach darum, den Artikwel immer mal anzusehen - und sodann um Hilfe.

[Felix Riesterer]

Lieber Raketenwilli,

nicht alle Unkundigen verwenden Linux, sondern im Gegenteil eher Windows - eben weil aus Unkenntnis. Daher finde ich (man kann das selbstverständlich auch anders sehen), dass eine Installation via apt und Konsorten wenig sinnvoll ist. Da hätte es noch eher einen Sinn, den composer zu verwenden, denn letzten Endes müssen alle „installierten“ Dateien auf dem Webspace (egal ob lokal oder online) liegen. Dass der Composer ein eigenes Tutorial bräuchte, ist mir natürlich klar, aber das haben andere auch schon verstanden und eines geschrieben.

Vielleicht magst Du für die Diskussion zu Deinen Arbeiten am Artikel einen neuen Thread eröffnen? Der hiesige ist etwas allgemeiner zu den Baustellen.

Liebe Grüße

Felix Riesterer

[Raketenwilli]

Alles klar. Hier geht es weiter.

[Tabellenkalk]

Hallo,

Ist das ne Drohung?!

Gruß
Kalk

[Raketenwilli]

Ist das ne Drohung?!

Menno: Nee. Der Link zur problematischen Seite wird automatisch eingebaut. HTML, CSS, JS & Co. überlasse ich gerne denen, die „Frontend“ machen. Ich fühl mich viel mehr fürs „Backend“ (da wäre z.B. PHP, Apache & Co.) und für das „Backend des Backends“ (also das Linux, Windows machen andere) zuständig.

[Matthias Scharwies]

Servus!

Ist das ne Drohung?!

Menno: Nee. Der Link zur problematischen Seite wird automatisch eingebaut.

Das kann man auch ändern!

Ich habe jetzt den Symfony-Teilthread vom Ursprungsthread gelöst!

HTML, CSS, JS & Co. überlasse ich gerne denen, die „Frontend“ machen. Ich fühl mich viel mehr fürs „Backend“ (da wäre z.B. PHP, Apache & Co.) und für das „Backend des Backends“ (also das Linux, Windows machen andere) zuständig.

Vielen Dank!

Heut abend shcreib' ich was zur Wiki-Syntax!

Soll ich das hier oder im neuen Thread machen?

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Ich habe jetzt den Symfony-Teilthread vom Ursprungsthread gelöst!

…

Heut abend shcreib' ich was zur Wiki-Syntax!

Soll ich das hier oder im neuen Thread machen?

Mach ruhig hier. Es wird sich schon jemand finden, der den Subthread dann rauslöst. 🤪

Kwakoni Yiquan

[Raketenwilli]

So. Hab allerhand geschrieben, programmiert und getestet.

Der Artikel ist jetzt mit funktionierendem Beispiel (wenn man ordentliche Daten zum Versender, Empfänger und DSN eingibt...) online und ich habe mutig - wenn nicht sogar wagemutig - die nicht mehr zum Titel passenden Inhalte des früheren „Formmailer“-Artikels gelöscht.

• Jetzt braucht er eine Review!

[Rolf B]

Hallo Raketenwilli,

ich hab mich mal rangemacht und schreibe hier auf, was mir auffiel. Wenn ich dabei erwähne: im Wiki macht dies so und jenes so, dann nimm das bitte einfach als Tipp für die Zukunft und nicht als Rüffel. Ich weiß ja, dass Du Wiki-Knowhow erst aufbaust.

Das Inhaltsverzeichnis habe ich auf 3 Ebenen limitiert, und deine Überschrift 2.1.1 (Installation mit BS-Mitteln) teils in den Textteil übertragen. Da stand ja schon der halbe Inhalt in der Überschrift.

Teilweise finde ich deine Schachtelungen sehr übertrieben, das ist ein Wiki und nicht Lisp 😉. In der Einleitung habe ich die Dreifachklammer mal aufgelöst.

Mail ist laut Duden feminin, nicht neutrum. Daran sollten wir uns halten, auch wenn dein persönlicher Duktus vielleicht "das Mail" sein sollte.

Für Kürzel wie z.B. oder d.h. haben wir Vorlagen, die eine schmale, geschützte Leerstelle zwischen die beiden Teile setzt. Das sind {{zB}} und {{dh}}. Am Satzanfang verwendet man {{zB|groß}} und {{dh|groß}}. Ich glaube zwar, dass nur ich die verwende, aber immer wenn ich ein d.h. finde oder gar ein d. h., dann setze ich sie ein.

Gedankenstriche bitte als – notieren. Es gibt zwar auch {{-}}, aber die liefert den non-breaking hyphen.

Die erste "ganz einfache" Installation hat mich verwirrt.

sudo apt install "php-symfony-google-mailer"

Ist da nicht ein google zu viel (wie so oft)? Danach folgt

apt install php-symfony-oh-my-smtp-mailer

Diesmal ohne Anführungszeichen. Ich nehme an, die "" sind nur nötig, wenn shell-relevante Zeichen im Paketnamen sind, aber es wäre ok, sie einfach "zur Sicherheit" zu setzen. Dann aber bitte durchgängig, ich habe sie bei oh-my-smtp mal ergänzt.

Die ständigen Anführungszeichen um „Symfony Mailer“ finde ich störend. An ein paar Stellen hast Du sie auch vergessen. Einmal zu Beginn ist ok. Kann man die rausmachen?

In deinem Testprogramm zur BS-Installation wird Egulias/EmailValidator eingebunden. Den hast Du vorher nicht erwähnt. Mich deucht aber, dass das ein Extrapaket wäre, und mich deucht weiter, dass das Beispiel ihn gar nicht braucht. Oder verdeuche ich mich da?

Inline-Code zeichnet man im Wiki mit <code>...</code> aus

Ich habe jetzt nur Kap. 1 und 2 durch, in der Versionshistorie findest Du meine Änderungen. Klicke auf einen der "Vorherige" Links, um die Version mit dem Vorgänger zu vergleichen.

Vielen Dank für den Artikel (oder kommt noch mehr 'rein?)

Rolf

[Raketenwilli]

Teilweise finde ich deine Schachtelungen sehr übertrieben, das ist ein Wiki und nicht Lisp 😉. In der Einleitung habe ich die Dreifachklammer mal aufgelöst.

Ja. Ich und der Kastensatz sind siamesische Zwillinge. Diagnose: „inoperapel“.

Die erste "ganz einfache" Installation hat mich verwirrt.

sudo apt install "php-symfony-google-mailer"

Ist da nicht ein google zu viel (wie so oft)?

Jepp: „Copy- & Paste-Error“

Danach folgt

apt install php-symfony-oh-my-smtp-mailer

Diesmal ohne Anführungszeichen. Ich nehme an, die "" sind nur nötig, wenn shell-relevante Zeichen im Paketnamen sind,

Jepp. Das kommt aber nur vor, wenn man den Paketname gerade nicht genau weiß oder mal fix ganze Paketgruppen installieren will.

aber es wäre ok, sie einfach "zur Sicherheit" zu setzen. Dann aber bitte durchgängig, ich habe sie bei oh-my-smtp mal ergänzt.

Und ich habe die Quotas bei beiden sodann weggemacht – weil ich Deinen letzten Satz wegen des Eilbedürfnisses (falsches "php-symfony-google-mailer") nicht gelesen hatte.

Die ständigen Anführungszeichen um „Symfony Mailer“ finde ich störend. An ein paar Stellen hast Du sie auch vergessen. Einmal zu Beginn ist ok. Kann man die rausmachen?

Ja. Diese und weitere Hinweise zur Auszeichnung werde ich morgen noch mal durchgehen und mir ansehen, was Du gemacht hast und schauen, ob ich etwas finde, welches Du vielleicht übersehen hast.

In deinem Testprogramm zur BS-Installation wird Egulias/EmailValidator eingebunden. Den hast Du vorher nicht erwähnt. Mich deucht aber, dass das ein Extrapaket wäre, und mich deucht weiter, dass das Beispiel ihn gar nicht braucht. Oder verdeuche ich mich da?

So tief stecke ich nicht drin. Aber wenn der Egulias/EmailValidator als Abhängigkeit automatisch installiert wird, dann wird der wohl auch intern benutzt (z.B. beim Hinzufügen der Adressen zum Mail-Objekt – immerhin ein sehr passender Zeitpunkt zum Validieren) und folglich gebraucht…

Inline-Code zeichnet man im Wiki mit <code>...</code> aus

Ich habe jetzt nur Kap. 1 und 2 durch, in der Versionshistorie findest Du meine Änderungen. Klicke auf einen der "Vorherige" Links, um die Version mit dem Vorgänger zu vergleichen.

Dafür danke ich → Dir.

Vielen Dank für den Artikel (oder kommt noch mehr 'rein?)

Zur Freude wohl vieler geht da eher was weg: Der Composer und dessen Setup hat eine eigene Wiki-Seite und über die muss ich mich (wie schon erwähnt) wohl auch hermachen. Es sieht aber nicht nach großen Änderungen aus - nur wenige Zeilen im Code und Mittel des OS (apt install composer) sowie die Folgen beider Wege aufzeigen. Wenn das alles überprüft (und an das Jahr 2024 angepasst ist) fliegt der Teil aus meinem Artikel raus und ich verweise dann dorthin.

Ich hoffe ja, dass niemand sauer ist, dass ich das Formmailer-Zeug entfernt habe. Aber zum Artikel über Symfony Mail passt das nicht gut.

[Rolf B]

Hallo Raketenwilli,

Ich hoffe ja, dass niemand sauer ist, dass ich das Formmailer-Zeug entfernt habe.

Keine Ahnung, da muss ich wohl noch mal in der Historie schauen, was da war. Aber das war doch Swiftmailer und wurde auch im Wiki als "nicht mehr empfehlenswert" benannt, oder?

Umfangreiches Laden einzelner Teile (require_once)

Schreibst Du bei beiden Installationsmethoden als Nachteil. Aber Du nennst keine Methode, wo dieser Nachteil nicht bestünde. Bei modularisierten Komponenten hat man diesen Nachteil wohl immer, es sei denn, es gäbe sowas wie Webpack für PHP. Ist der Nachteil überhaupt relevant? Opcache und PHP Jit dürften das doch gut kompensieren. Deswegen: wenn's unvermeidlich ist, braucht man es nicht als Nachteil aufzuführen. Wenn's ein Copyfehler war oder man was tun kann, dann müsste man drauf eingehen. Find ich.

Ob dein Formularcode in dieser Pracht zum Mailer passt, weiß ich auch nicht. Deklarative Fehlerprüfung schön und gut, aber das bläht den Code extrem auf und eigentlich soll ja Symfony gezeigt werden. Wäre es schlimm für Dich, die Plausi spezifisch und minimalistisch für dieses Form zu bauen? Generell bin ich ja ein Fan solcher Konstrukte, erstelle dann aber Klassen und abstrahiere noch stärker. Das wäre dann aber eher ein eigener Artikel und ich weiß nicht, ob das für Selfhtml zu sehr out-of-scope ist.

Rolf

[Matthias Scharwies]

Guten Morgen Jörg,

Vielen Dank für deine Arbeit!

Ich hoffe ja, dass niemand sauer ist, dass ich das Formmailer-Zeug entfernt habe.

Nein!

Keine Ahnung, da muss ich wohl noch mal in der Historie schauen, was da war. Aber das war doch Swiftmailer und wurde auch im Wiki als "nicht mehr empfehlenswert" benannt, oder?

Ich habe nur die Info-Box (mit Link zum SELFHTMl-Aktuell-Artikel aus 2002!) unterhalb der Referenzen sowie die Kategorien wiederhergestellt und dafür auch noch 3 Cards eingefügt:

• PHP/Tutorials/Symfony_Mailer#Siehe_auch

Auch die alten SELFHTML-Aktuell-Artikel fingen nach dem Seitentitel(h1) gleich mit einer h2-Überschrift an. Ich habe die ersten zwei Überschriften entfernt, da gleich nach der h1 eine Einleitung kommen kann.

Damit der Abschnitt Sinnhaftigkeit nicht überlesen wird, habe ich ihn in ein {{Beachten|...}} gesteckt.

Evtl. kann man den Abschnitt Vorbetrachtungen auch nach oben ziehen - bevor es losgeht. Dann würde das Szenario direkt unter dem Seitenanker stehen und es gäbe keinen inhaltlichen Sprung.

Gerade in diesem Abschnitt fällt mir auf, dass Deine Linktexte ziemlich lang sind und dem Nutzer nur klar ist, dass er aus SELFHTML rauskommt - aber nicht, wohin.

Alternativen wären Fußnoten, die dann aber evtl. untergehen.

Ich habe noch zwei Links per Vorlage {{Hauptartikel|Seitenname}} eingefügt.

Nicht in diesem Abschnitt, aber davor fehlt wohl die Hälfte des Satzes.

Nochmals vielen Dank! Können/ sollen wir irgendwie die Autorenschaft kennzeichnen? Einerseits ist es ein Wiki, andererseits könnte man so auch die Zielgruppe einfangen, in dem man mit Name, Erfahrung, Erlebnissen anfängt.

Herzliche Grüße

Matthias Scharwies

[Raketenwilli]

Guten Morgen Jörg,

Vielen Dank für deine Arbeit!

Ich hoffe ja, dass niemand sauer ist, dass ich das Formmailer-Zeug entfernt habe.

Nein!

Keine Ahnung, da muss ich wohl noch mal in der Historie schauen, was da war. Aber das war doch Swiftmailer und wurde auch im Wiki als "nicht mehr empfehlenswert" benannt, oder?

Naja. Ursprünglich ging es in meiner Erinnerung um einen Formmailer. In den wurde dann das Swiftding eingebaut und irgendwann der Artikel umbenannt. Anfänglich ging es also vor allem um die Verarbeitung der Formulardaten, erst später um den Versand.

Ich habe nur die Info-Box (mit Link zum SELFHTMl-Aktuell-Artikel aus 2002!) unterhalb der Referenzen sowie die Kategorien wiederhergestellt und dafür auch noch 3 Cards eingefügt:

• PHP/Tutorials/Symfony_Mailer#Siehe_auch

Auch die alten SELFHTML-Aktuell-Artikel fingen nach dem Seitentitel(h1) gleich mit einer h2-Überschrift an. Ich habe die ersten zwei Überschriften entfernt, da gleich nach der h1 eine Einleitung kommen kann.

Damit der Abschnitt Sinnhaftigkeit nicht überlesen wird, habe ich ihn in ein {{Beachten|...}} gesteckt.

Evtl. kann man den Abschnitt Vorbetrachtungen auch nach oben ziehen - bevor es losgeht. Dann würde das Szenario direkt unter dem Seitenanker stehen und es gäbe keinen inhaltlichen Sprung.

Ich denke, das wäre ein noch größerer Spruung. Die Vorbetrachtungen gehören zum Anwendungsbeispiel und nicht zum Symfony Mailer.

Gerade in diesem Abschnitt fällt mir auf, dass Deine Linktexte ziemlich lang sind und dem Nutzer nur klar ist, dass er aus SELFHTML rauskommt - aber nicht, wohin.

Alternativen wären Fußnoten, die dann aber evtl. untergehen.

Jepp. Deswegen keine Fußnoten. Denen folgt kaum jemand.

Ich habe noch zwei Links per Vorlage {{Hauptartikel|Seitenname}} eingefügt.

Nicht in diesem Abschnitt, aber davor fehlt wohl die Hälfte des Satzes.

Au ja. Da hatte ich innegehalten, weil der Zeitpunkt in Sekunden als „ID“ eine „bad idea“ war − und das dann vergessen. Hab den Zeitpunkt durch eine unigue ID ersetzt. Das auch nur, weil ich nicht auch noch eine Session einbauen wollte.

Nochmals vielen Dank! Können/ sollen wir irgendwie die Autorenschaft kennzeichnen?

*Beware! *

Einerseits ist es ein Wiki,

Deswegen. Dann stände mein Name womöglich über der Leistung eines Dritten.

andererseits könnte man so auch die Zielgruppe einfangen, in dem man mit Name, Erfahrung, Erlebnissen anfängt.

„Ist ein „Boomer“ (vorletzer Jahrgang!). Hat im vorigen Jahrtausend den ehrlichen Beruf eines Schlossers erlernt, straflos fast die ganze Nationale Volksarmee der DDR durcheinandergebracht, ist im neuen Jahrtausend infolge einer dreistelligen Anzahl verlogener Strafanzeigen von kriminellen RechtsAbmahnanwälten der Zivilist mit dem meisten Freisprüchen in Deutschland und der einzige Bundesbürger, dem es ohne Anwalt gelang, in einem Zivilverfahren gleich vier Richter eines teutonischen Landgerichts wegen derer Voreingenommenheit abzulehnen (und das Verfahren selbst dann auch noch durch vollständige Klagerücknahme zu gewinnen), hat sich im BWL-Studium zuviel mit Programmieren befasst und war mit BWL-Jobs höchst unglücklich. Prostituiert sich deshalb seit der Jahrtausendwende als freiberuflicher IT-Dozent und Trainer - gibt aber definitiv nur Kurse, die ihm auch Spaß machen und kariolt dafür im Sommer gerne mit einem als Wohnmobil genutztem Leicht-LKW nebst beigeladenem E-Bike und Motorroller in schöne Gegenden.“

Hm. Das will doch in einem IT-Fachwiki keine(r) lesen.

[Raketenwilli]

Umfangreiches Laden einzelner Teile (require_once)

Schreibst Du bei beiden Installationsmethoden als Nachteil.

[x] Behoben.

Ob dein Formularcode in dieser Pracht zum Mailer passt, weiß ich auch nicht. Deklarative Fehlerprüfung schön und gut, aber das bläht den Code extrem auf und eigentlich soll ja Symfony gezeigt werden. ... Wäre es schlimm für Dich, die Plausi spezifisch und minimalistisch für dieses Form zu bauen?

Da werd ich noch etwas über das Beispiel nachdenken müssen.

Generell bin ich ja ein Fan solcher Konstrukte, erstelle dann aber Klassen und abstrahiere noch stärker.

Ich mach das nicht bei Inselaufgaben, die Ihrer Natur nach „Spaghetti“ sind. (Szenario).

Aber möglicherweise wäre das Auslagern der Plausibilitätsprüfung in einen eogenen Skript-Teil, der wie das Formular und die Danke-Seite nichts mit Symfony zu tun hat, eine Möglichkeit das Kernskript zu verschlanken.

[Rolf B]

Hallo Raketenwilli,

okay.

Und eins noch: Ich habe jetzt eine Weile damit verbracht, jede von Dir erzeugte Artikelversion als "kontrolliert" zu markieren. Das ist ein Wiki-Feature, mit dem wir vor allem Änderungen von Trollen erkennen wollen. In deinem Fall wurde es eher lästig…

Das Recht, eigene oder fremde Änderungen zu kontrollieren (autopatrol / patrol), ist nur für Wiki-Admins eingerichtet. Für Leute wie Dich bräuchten wir eigentlich eine eigene Usergruppe "Vertrauenswürdig" - hm. Dafür muss man in der LocalSettings.php rumwuseln, ungern, sehr ungern.

Häufiges Speichern ist für Entwickler ja eigentlich Pflicht, aber falls es Dir nur darum ging, das Aussehen deiner Änderung zu kontrollieren, kannst du auch die Vorschau-Funktion verwenden.

Rolf

[Raketenwilli]

Und eins noch: Ich habe jetzt eine Weile damit verbracht, jede von Dir erzeugte Artikelversion als "kontrolliert" zu markieren. Das ist ein Wiki-Feature, mit dem wir vor allem Änderungen von Trollen erkennen wollen. In deinem Fall wurde es eher lästig…

Ah. Verstehe. Nicht so viele kleinteilige Änderungen.

Ich sollte mir lokal was bauen, was den Quelltest hinreichend ähnlich wieder gibt. Gibt zu Umwandeln in HTML bestimmt eine Lib dafür - oder?

[Rolf B]

Hallo Raketenwilli,

Gibt zu Umwandeln in HTML bestimmt eine Lib dafür - oder?

Was willst Du nach HTML umwandeln?

PHP Quellcode mach als Beispiel im Wiki, das bau ich Dir mal exemplarisch ein

Ich hätte noch Input für deinen Thinking Hat: Was nützt es, auf Fehler mit HTTP 204 und Stillschweigen zu reagieren? Ein Normaluser muss vom Mailformular erfahren, welche Eingaben Pflicht sind und welche Grenzen die Werte einzuhalten haben, das ist eine Mindestanforderung an die Benutzbarkeit. Ein bösartiger User, der weiß, dass hier ein Mailformular ist, kann ebenfalls lesen und hat diese Info deshalb auch. Deshalb würde ich auf sinnvolle und hilfreiche Fehlermeldungen keinesfalls verzichten wollen.

Aber: für den Mailer würde ich die Plausi nur als Kommentar andeuten („muss sein und hier gehört sie hin“), für die Realisierung des Affenformulars aber auf den vorhandenen Artikel zu PHP Formularen verweisen. Musterimplementierungen zu einer tabellengetriebenen Validierung könnten dort besser aufgehoben sein. Ich weiß, dass ich damit deinem Baby gerade einen Arm und ein Bein ausreiße, deshalb kann ich verstehen, wenn Dir das nicht passt. Aber denk mal drüber nach.

Rolf

[Raketenwilli]

Gibt zu Umwandeln in HTML bestimmt eine Lib dafür - oder?

Was willst Du nach HTML umwandeln?

Den im Wiki zu notierenden Text.

[Rolf B]

Hallo Raketenwilli,

der Rahmen für die Beispielvorlage im Wiki ist:

{{Beispiel|titel=Datei: Formular.html|
{{BeispielText|
Dieses ist das HTML-Formular, mit dem die Daten gesendet werden.
}}
{{BeispielCode|
<source lang="html">
</source>
}}
}}

Den Dateinamen für deine Scriptteile kannst Du mit dem titel-Parameter als Titel vergeben, der braucht IMO nicht ins Inhaltsverzeichnis. Den zeige-Parameter der Beispielvorlage lassen wir weg, für PHP gibt's kein Frickl (unser einfaches Weblabor).

Als Inhalt der Beispielvorlage verwendet man dann die Untervorlagen {{BeispielText|...}} für einfachen Text und {{BeispielCode|...}} für Codeteile. Diese Reihenfolge der Untervorlagen ist beliebig und jede kann 0-N Mal verwendet werden.

Rolf

[Raketenwilli]

der Rahmen für die Beispielvorlage im Wiki ist:

{{Beispiel|titel=Datei: Formular.html|
{{BeispielText|
Dieses ist das HTML-Formular, mit dem die Daten gesendet werden.
}}
{{BeispielCode|
<source lang="html">
</source>
}}
}}

Den Dateinamen für deine Scriptteile kannst Du mit dem titel-Parameter als Titel vergeben, der braucht IMO nicht ins Inhaltsverzeichnis. Den zeige-Parameter der Beispielvorlage lassen wir weg, für PHP gibt's kein Frickl (unser einfaches Weblabor). Hab auch schon gesehen, dass das geändert wurde: Danke!

Hab das - zwecks Wiederfindens - mal unter einem schnell findbaren Topic abgelegt.

[MudGuard]

Hi,

Ah. Verstehe. Nicht so viele kleinteilige Änderungen.

Ich sollte mir lokal was bauen, was den Quelltest hinreichend ähnlich wieder gibt. Gibt zu Umwandeln in HTML bestimmt eine Lib dafür - oder?

Ich meine, hier mal mitgelesen zu haben, daß man im Wiki einen eigenen Bereich zum Experimentieren anlegen kann. Dann könntest Du die Seite dorthin kopieren, ändern wie Du lustig bist, und wenn Du fertig bist, zurück in's öffentliche Wiki schieben.

cu,
Andreas a/k/a MudGuard

[Matthias Scharwies]

Servus!

Hi,

Ah. Verstehe. Nicht so viele kleinteilige Änderungen.

Ich schreibe lokal und kopier's dann in die Seite. Ab da arbeite ich mit "Vorschau zeigen".

Ich sollte mir lokal was bauen, was den Quelltest hinreichend ähnlich wieder gibt. Gibt zu Umwandeln in HTML bestimmt eine Lib dafür - oder?

Ich meine, hier mal mitgelesen zu haben, daß man im Wiki einen eigenen Bereich zum Experimentieren anlegen kann. Dann könntest Du die Seite dorthin kopieren, ändern wie Du lustig bist, und wenn Du fertig bist, zurück in's öffentliche Wiki schieben.

Ja, das wäre einfach eine Seite wie Benutzer:MScharwies/test

Andererseits haben wir fast nur noch Edits und Arbeit mit bestehenden Seiten. Dort ist es oft besser gleich im Artikel punktuell zu verbessern; anstatt in mehreren Benutzerräumen jeweils angefangene Verbesserungen zu haben.

Deshalb auch die Baustellen im Wiki-Seite, damit sich nichts überschneidet.

Herzliche Grüße

Matthias Scharwies

[Raketenwilli]

Ja, das wäre einfach eine Seite wie Benutzer:MScharwies/test

Suppy!

Hab die URL mal mit meinem Nutzername verquickt - und siehe da: Es geht.

[MudGuard]

Hi,

Ja, das wäre einfach eine Seite wie Benutzer:MScharwies/test

war ja nur ein Gedanke, damit Raketen-Seitenänderungen nicht sofort bei Dir oder Rolf aufschlagen.

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo MudGuard,

hilft nix, Änderungen im Benutzer-Namespace werden auch als unkontrolliert markiert. Man könnte dann höchstens alle Zwischenversionen löschen, sofern das Patrol-Plugin damit klar kommt. Das ist nicht ganz fehlerfrei. Eine Funktion "setze alle markierten Änderungen auf kontrolliert" gips nicht. Und Mediawiki speichert auch alle gelöschten Revisionen, ganz rausschmeißen geht - meine ich - nicht.

Rolf

[Raketenwilli]

hilft nix, Änderungen im Benutzer-Namespace werden auch als unkontrolliert markiert.

Hm. Dann hilft gegen dieses Unbill nur das lange offenlassen der Bearbeitung nebst Vorschau – Das „lange offenlassen“ bzw. birgt aber mangels Speicherung die Gefahr eines Datenverlustes.

Dann brauch ich wohl doch einen lokalen parser, der mir aus dem Text im lokalen Editor eine HTML-Vorschau erstellt.

Oder ich installiere mir halt ein komplettes MediaWiki…

[Rolf B]

Hallo Raketenwilli,

dein lokaler Parser oder dein lokales Mediawiki hat dann aber nicht unsere Vorlagen oder Extensions.

Eine Wiki-Extension wie im Forum, die jede Änderung im localStorage puffert und nach einem Crash zurückholt, wäre schick, hamma aba nich.

Obwooooohl… ist ja eigentlich simpel, das sollte doch…

Könnte ein 🐇🥚 werden

Rolf