Wenn ihr in einem Projekt die Anforderung habt, Eingaben aus (Kontakt)Formularen zu speicher, wie geht ihr damit um? 1. Die Form-Extension nutzen und den saveToDatabase-Finisher verwenden? (Was zur Folge hat, dass man evtl. auch noch Felder in der DB anlegen muss) 2. Powermail nutzen? (Gibt es inzwischen auch für TYPO3 12) 3. Die Extension "form_to_database" verwenden? (Gibt es leider noch nicht für v12) 4. Was ganz anderes? Ich habe bisher alle der ersten 3 Optionen genutzt, je nach Projekt. Haben halt alle ihre Vor- und Nachteile.

Ich würde auf jeden Fall die Formular-Technik beibehalten, die es bereits gibt. Bei neueren Instanzen wäre das bei mir die `EXT:form`. Da ich ungern neue Abhängigkeiten durch weitere Drittanbieter Extensions reinbringen möchte, würde ich dementsprechend wahrscheinlich den saveToDatabase Finisher benutzen. Wenn das mapping auf bereits existierende Tabellen/Felder nicht ausreicht müsste man neue anlegen. Für solche Formulardaten würde ich aber eigentlich sowieso eine neue dedizierte Tabelle mit den entsprechenden Feldern verwenden. Hm, müsste das Anlegen eigener Records nicht sogar mittlerweile mit Content Blocks gehen?

@"Wolfgang Wagner"#p1806 Ich bevorzuge in diesem Fall Powermail. Die EXT:form hat mich bislang nie so ganz zufriedenstellen können und ich fand sie etwas sperrig. Allerdings ist mein letzter Versuch jetzt auch schon wieder 2 Jahre her.

Ob das mit "Content Blocks" geht, weiss ich nicht. Ich musste bisher halt immer TCA und eine ext_tables.sql anlegen, das hat für den Finisher funktioniert. Ist halt ne relativ starre Lösung, bei neuen Formularen oder wenn bestehende Formulare verändert werden, muss man da immer auch nochmal ran.

Bei uns ist idR in allen Projekten Powermail installiert. Wobei wir aus Datenschutzgründen auch unseren Kunden dazu raten, keine Mails in der Datenbank zu speichern. Soll es doch nötig sein, setzen wir unseren Powermail-Cleaner ein, der per scheduler die Daten der gewünschten Formulare nach definierter Zeit löscht.

Ich nutze nahezu immer die ext form_to_database, sofern ich Formulare brauche. Mich würde da als Gegenfrage interessieren, welche Reihenfolge der Finisher Ihr nutzt? Ich speichere immer erst in der Datenbank und erst danach sende ich die Mails. Erfahrungsgemäß gibt es leider immer wieder PRobleme bei der Zustellung der Mails bei Kunden (aus diversen Gründen) so dass ich den Fallback der in der gespeicherten Mails in der Datenbank bereits sehr oft bedienen musste.

Ich glaube, dass die Reihenfolge relativ egal ist, solange der Redirect-Finisher als letztes ausgeführt wird. Denn der muss der letzte sein, siehe https://docs.typo3.org/c/typo3/cms-form/12.4/en-us/I/Concepts/Finishers/Index.html Aber wahrscheinlich ist es sinnvoll, zuerst zu speichern. Zum Thema E-Mailzustellung: Hier wird es halt immer wichtiger, dass alles sorgfältig konfiguriert ist, nicht nur in TYPO3, sondern auch beim Hoster. Die Absender-Adresse muss zur Domain passen, SPF-Record, DKIM, DMARC... das muss heutzutage alles passen, sonst kommen die Mails nicht zuverlässig an.

> @"Eric Harrer"#p1807 Hm, müsste das Anlegen eigener Records nicht sogar mittlerweile mit Content Blocks gehen? Du kannst auf jeden Fall Record-Types mit Content Blocks anlegen. Aber die Records dann danach speichern, geht nicht. CB legt ja "nur" das TCA für die Record-Types und Content Elemente an, also so, als wenn du das alles selbst schreiben würdest, nur halt einfacher.

@"Wolfgang Wagner"#p1825 Genau darauf zielte der Gedanke mit lieber erstmal in der Datenbank speichern und danach versenden ab. Es haben bereits mehrere Kunden versäumt, die SPF, DKIM und DMARC richtig zu setzen und/oder die Firewall nicht richtig konfiguriert, da waren die Formulare in der Datenbank Gold wert und der Kunde war endlos happy. Wichtig dabei, den Kunden zu unterweisen, dass er regelmäßig die Formulare in der Datenbank löschen soll. Je nach Anwendungsfall habe ich da Spielräume von bis zu 1 Jahr Aufbewahrungszeit vom Datenschützer freigegeben bekommen. Also 2x pro Jahr aufräumen, schadet ja eh nicht. Und ein weiterer Gedanke bei erst in DB speichern und dann per Mail versenden ist, hast Du ein Konfigurationsfehler bei deinen Mail-Einstellungen im TYPO3, kann es zu einem Fehler führen, was das danach erst speichern unmöglich machen könnte. Daher speichere ich immer erst und dann kommt die Mail. Der Finisher für Redirect oder Textausgabe am Ende ... sollte in der Tat als Letztes erfolgen ;-)

Formulardaten speichern?

Wolfgang Wagner

Das löschen müsste doch eigentlich per Scheduler machbar sein.

Axel Hempelt

Wolfgang Wagner Ja, geht natürlich über den Scheduler. Bei meiner Antwort war ich gedanklich bei dem einen Kunden, der das bewusst manuell machen will. Er gleicht die Einträge erst noch einemal mit seinem CMS ab und wenn dann alles okay, dann löscht er es manuell. Halt doppelter Boden...

Thomas Hilburger

Jetzt kommt mit für längere Formulare aus denen am Ende eine Mail oder gar ein PDF werden soll die Frage auf, wie es um ein Zwischenspeichern steht?
Bei längeren Formularen ist ein Zwischenspeichern sehr sinnvoll.
Wie würdet Ihr hierbei tendenziell vorgehen? Gleich eine eigene Ext schreiben?

Markus Hofmann

Thomas Hilburger

Ich empfehle da die EXT:form_to_database. Die speichert dir die Daten in einem JSON-Format passend ab und du kannst dann in einem eigenen Scheduler-Task/CLI/whatever die Daten aus der DB auslesen und damit machen, was du willst.

Die extension ist auch gerade auf dem besten Weg, v13 ready zu werden (bin selbst dran beteiligt und sieht aktuell gut aus).

Olaf

Markus Hofmann Mir ist nicht klar, wie Du das für längere Formulare zum Zwischenspeichern einsetzt... Kannst Du mir gedanklich auf die Sprünge helfen? Meine Gedanlen gehen in die Richtung per JS einen autosave aller x Sekunden zu triggern, ich bekomme es dann aber nicht weiter an die Extension (oder hab nen Denkfehler ;-)

Sven Kalbhenn

Ich verwende dafür die Extension "pagemachine/typo3-formlog". Die gibt es auch für TYPO3 v12.
Der Hauptgrund, warum ich mich für diese Extension entschieden habe, war die Anforderung des Kunden, dann immer auch einen CSV/Excel-Export von bestimmten Formular-Feldern zur Verfügung zu haben. Bei dieser Extension kann man im TypoScript-Setup entsprechende Export-Templates definieren, die der Kunde dann einfach auswählen kann, um die gewünschte Liste zu exportieren.
Außerdem liefert diese Extension auch einen Scheduler-Task mit, um alte Formular-Einträge zu löschen.

Markus Hofmann

Olaf Puh, da verstehe ich die Frage nicht.

Wenn du mehrseitige Formulare hast, kümmert sich ja das form Framework darum, die Einträge entsprechend zwischenzuspeichern. form_to_database speichert nur das Endresultat als JSON in die Datenbank.

Mogens Fiebrandt

Das Zwischenspeichern in der DB ist ja auch etwas problematisch.
Was ist, wenn der Benutzer das Formular am Ende gar nicht absendet oder die Seite einfach mittendrin verlässt?
Dann hat man unvollständige Daten.

Zudem hat der Nutzer vielleicht dann auch noch nicht der Speicherung zugestimmt und weiß vielleicht/wahrscheinlich auch nicht, dass die Daten die er gerade eingibt per Ajax bereits gespeichert werden.

Sollten diese Probleme auf irgendeine Weise gelöst sein. Dann würde ich eher ein JavaScript-Event verwenden, dass bei Änderung des Formulars getriggert wird.
Aber ich verstehe hier auch noch nicht so ganz den Use-Case.

Olaf

Danke für Eure Rückmeldungen! Es geht um sehr umfangreiche, mehrseitige Formulare mit Dokumenten/Fragen die ggf. erst besorgt werden müssen - es soll darum gehen, als Benutzer das Formular heute zu beginnen und dann die Chance zu haben morgen an der selben Stelle weiter arbeiten zu können und somit die bereits eingegeben Daten eben durch das System vorgehalten werden-das man damit auch "Müll" produziert ist mir sehr bewußt, ließe sich aber durch bereinigen nach x Tagen oder so umgehen.

Markus Hofmann

Olaf Okay, wenn es darum geht, kannst du zum Beispiel mit dem localStorage im Browser arbeiten und die Daten dort zwischenspeichern, bis du sie am Ende komplett in die DB schreibst.

Olaf

Markus Hofmann Naja, das hat ein Nachteile/Risiken da es "nur" beim Benutzer lokal liegt gibt es bei geteilen Systemen ggf. ein Sicherheitsthema und auch ein Wechsel der Geräte ist für den Benutzer nicht möglich. Daher wäre mir eine Ablage über den authentifizierten Benutzer in der DB deutlich lieber.

Markus Hofmann

Olaf Wenn du einen autentifizierten User hast, dann kannst du das ja in der entsprechenden Session speichern, also am User selbst. Das kommt dann auf das gleiche wie localStorage raus.
Das kommt halt immer auf den Anwendungsfall raus, was gewünscht ist, wenn es bei dir eben um schützenswerte Daten geht, dann kannst du eben eine simple Mapping-Tabelle erstellen, welche für den FE-User einen DFatensatz schreibt, der dann eben zwischengespeichert wird.

Ich würde allerdings changed und created mit speichern, um erfassen zu können, wann der Datensatz das letzte Mal bearbeitet wurde, im aufräumen zu können. SOlche Tabellen müllen gern schnell zu.

« Vorherige Seite

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS