9 Dinge, die ich nicht über die Finisher im TYPO3 Form Framework wusste
Der Titel klingt nach billigem Clickbait, der Inhalt ist aber, was ich innerhalb der letzten Woche auf die harte Tour lernen musste.
Szenario: zweisprachige TYPO3 Seite mit einem Kontaktformular aus einer Konfigurationsdatei. Klingt ja erstmal nicht aufregend, wird es aber spätestens, wenn wir die Mails im Finisher in unterschiedlichen Sprachen konfigurieren möchten. Also weil wir sowas Triviales machen wollen, wie der Kund:in eine Bestätigung in ihrer Sprache senden wollen. Oder wir die Eingaben in einem internationalen Kontext an eine Ansprechpartner:in leiten wollen, die nicht alle möglichen Sprachen ihres Zielmarktes spricht.
Der folgende Text ist kein Tutorial für mehrsprachige Formulare oder E-Mails. Das hat Sebastian auf sebkln.de schon absolut erstklassig beschrieben.
1 - Das Form-Framework ist absolut unnachgiebig bezüglich falscher Konfiguration.
Was einmal irgendwo konfiguriert wurde und dann in einem Finisher-Override festgeschrieben wurde, das bleibt und ist nur durch harte Maßnahmen wegzubekommen
Lösungsmöglichkeit 1: Ich weiß, was ich alles geändert habe, und überschreibe es händisch im Finisher.
Lösungsmöglichkeit 2: Ich lösche entweder das Feld pi_flexform oder einfach gleich das ganze Formular.
2 - Das Form-Framwork ist ignorant gegenüber den TYPO3-Spracheinstellungen.
In den Finsher-Overrides kann man die Zielsprache einstellen. Leider findet man dort initial nur den Eintrag "Default" vor, weil das Framework hier offensichtlich nicht die aktiven Sprachen der Instanz ermitteln kann. Und zudem ist "Default" auch nicht die "Default"-Sprache der Instanz, sondern "TYPO3-Default", nämlich Englisch. Also sind auch auf einer deutschen Seite mit einer englischen Übersetzung erst mal alle Labels in Englisch, sofern sie aus Übersetzungsdateien kommen. Lösung: Die weiteren Sprachen müssen in einer /f7forms/Configuration/Yaml/Finishers/EmailToReceiver.yaml angemeldet werden:
prototypes:
standard:
finishersDefinition:
EmailToReceiver:
FormEngine:
elements:
translation:
language:
config:
items:
20:
label: Deutsch
value: de3 - In den Finisher-Overrides kann man keine Feldnamen als E-Mail Adressen nutzen.
In den Definitionsdateien und im Form-Editor kann man Feldnamen als Quelle für alle möglichen Werte im Finisher nutzen. senderName: '{first_name} {last_name}' , senderAddress: {email}. Das ist praktisch und auch Redakteuren zu vermitteln, die sich selber Formulare zusammenklicken möchten. In den Finisher-Overrides wird die Eingabe von {email} im Sender (oder jedem anderen Feld) quittiert mit dem Hinweis, dass man in die Felder nur E-Mail-Adressen eingeben kann. Feldvalidierung an der falschen Stelle. Lösung: Die entsprechenden Felder müssen in einer /f7forms/Configuration/Yaml/Finishers/EmailToReceiver.yaml umkonfiguriert werden:
prototypes:
standard:
finishersDefinition:
EmailToReceiver:
FormEngine:
elements:
recipients:
el:
_arrayContainer:
el:
email:
config:
type: input
replyToRecipients:
carbonCopyRecipients:
blindCarbonCopyRecipients:4 - Es werden nur Text- aber keine HTML-Mails verschickt.
Das passiert möglicherweise nur Entwicklern, die (wie ich) der Meinung sind, dass "addHtmlPart" ja in der Dokumentation als "true" definiert ist und man die entsprechende Zeile in der Konfigurationsdatei einsparen kann. Steht ja auch im Code der EmailFinisher.php bei den $defaultOptions so drin. Klappt aber aus mir aktuell unbekannten Gründen nicht. Lösung: In der Konfigurationsdatei muss addHtmlPart definiert werden, sonst ist der Wert "false"
finishers:
- identifier: EmailToReceiver
options:
addHtmlPart: true5 - Es werden keine Anhänge an die Mails angehängt.
Siehe den vorherigen Punkt und ersetzte addHtmlPart gegen attachUploads.
6 - Die verschickte HTML-E-Mail hat immer das TYPO3-Logo oben drin und einen orangen Hintergrund.
Hier mach sich das Form-Framework das Thema E-Mail-Erstellung sehr einfach und übernimmt einfach die TYPO3-Systemeinstellungen. TYPO3 nutzt, weil es selber keinen Bedarf für individuelle Mails hat, der Einfachheit halber die Werte, die auch für den Backend-Login genutzt werden. Lösungsmöglichkeit 1: In der Datei /config/system/settings.php müssen folgende Felder mit kundenspezifischen Werten definiert werden:
[
'backend' => [
'loginHighlightColor' => '#...',
'loginLogo' => 'EXT:...',
],
],
];Das hat zudem den angenehmen Nebeneffekt, dass auch der Backend-Login auf den Kunden gebrandet wird, was durchaus positiv wahrgenommen wird. Lösungsmöglichkeit 2: Das E-Mail-Layout überschreiben -> siehe nächster Punkt.
7 - Die verschickten Mails haben immer einen "TYPO3 Disclaimer" am Ende stehen.
Als systemtreuer Entwickler freue ich mich natürlich über jede Aufmerksamkeit, die mein Lieblings-CMS bekommt, kann aber nachvollziehen, wenn Kund:innen es nicht gut finden, dass bei jeder Mail, die von der professionell aussehenden Webseite verschickt wird, einen Text von diesem "obskuren TYPO3" am Ende hat. Lösung: Ein kundenspezifisches E-Mail-Layout muss her. Angemeldet wird dass dann in der /f7forms/Configuration/Yaml/Finishers/EmailToReceiver.yaml
prototypes:
standard:
finishersDefinition:
EmailToReceiver:
options:
layoutRootPaths:
20: 'EXT:f7forms/Resources/Private/Layouts/Form/Frontend/Finishers/Email/'
templateRootPaths:
20: 'EXT:f7forms/Resources/Private/Templates/Form/Frontend/Finishers/Email/'
partialRootPaths:
20: 'EXT:f7forms/Resources/Private/Partials/Form/Frontend/Finishers/Email/'Als Inspiration findet man das TYPO3-eigene Layout "SystemEmail" sowohl als HTML als auch als TXT in vendor/typo3/cms-core/Resources/Private/Layouts. Und das "Default"-Template in vendor/typo3/cms-core/Resources/Private/Templates/Email.
8 - Die Mail an den Empfänger wird nicht verschickt. Die Fehlermeldung sagt etwas von falscher Domain oder falscher Region.
Damit die Empfänger einfach auf die eingehende E-Mail antworten können, wird senderAddress gerne mal auf {email} gesetzt. Dann steht ja die Adresse des Absenders in der Mail und wenn man auf Antworten klickt, hat man gleich die richtige Adresse im Programm. Nun kommt es aber immer häufiger vor, dass E-Mail Server sauber und sicher konfiguriert werden und nur E-Mails mit bekannten Absendern verschicken. Also in der Regel eine Absenderdomain haben, die auf dem Server eingerichtet ist. Da die wenigsten Kontaktanfragen von der eigenen Domain verschickt werden, muss der Finisher anders konfiguriert werden:
finishers:
- identifier: EmailToReceiver
options:
senderAddress: no_reply@eigenerserver.tld
replyToRecipients:
'{email}': '{firstname} {lastname}'
9 - Das Form-Framework braucht Hilfe.
Nachdem ihr oben hoffentlich ein paar Dinge entweder gelernt habt oder zumindest aufgefrischt habt, kommen wir doch noch zum Click-Bait. Das TYPO3-Form-Framework ist meiner Meinung nach ein extrem starkes Stück mit vielen Funktionen. Leider hat es auch ein paar fiese Bugs (vieles von dem oben geschriebenen würde ich so klassifizieren), die besonders Entwicklern den Spaß am System manchmal verderben. Zudem hat das Framework in den vergangenen Monaten viel Developer-Power verloren und daher wenig Liebe bekommen. Daher mein Appell an alle Leser:innen: Schaut in Forge, was es zu tun gibt und helft mit, das System nach vorne zu bringen.
Autor:in
