Erstellung benutzerdefinierter E-Mail-Vorlagen und Transaktions-E-Mail-Logik in PrestaShop

Uns fällt auf, dass jeder PrestaShop-Shop wöchentlich unzählige E-Mails versendet, ohne dass sich jemand Gedanken darüber macht: Bestellbestätigungen, Versandbenachrichtigungen, Passwort-Resets, Willkommensnachrichten für neue Kunden. Dann leitet ein Kunde eine dieser E-Mails weiter und fragt: „Moment mal, ist die wirklich von Ihnen?“ Das Template hat zwar immer noch den klassischen, altmodischen PrestaShop-Look, aber irgendwie wirkt das E-Mail-System jetzt modern und durchdacht.

Das Anpassen von PrestaShop-E-Mail-Vorlagen ist eigentlich keine einzelne Aufgabe. Es handelt sich vielmehr um zwei Probleme, die auf den ersten Blick ähnlich erscheinen. Zum einen geht es um das Aussehen der E-Mail, zum anderen darum, wann und warum sie überhaupt versendet wird. Die meisten Anleitungen behandeln nur den ersten Punkt. Dieser Artikel hingegen behandelt beide, denn Shopbetreiber, die sich nur mit der visuellen Vorlage befassen, stoßen irgendwann an ihre Grenzen, sobald sie eine individuelle Benachrichtigung wünschen, beispielsweise eine E-Mail wie „Ihre Bestellung ist wieder verfügbar“, die PrestaShop standardmäßig nicht versendet.

1.0 Wie PrestaShop tatsächlich E-Mails verarbeitet

Die Modifizierung der Templates bedeutet, die Ergebnisse der Logik zu verändern, ohne die Logik selbst anzufassen. Es wäre hilfreich, ein gewisses Verständnis der Struktur zu haben, bevor man Änderungen vornimmt, da PrestaShop seine E-Mail-Verarbeitungsfunktionalität in zwei separate Ebenen an völlig unterschiedlichen Orten unterteilt.

Die erste Ebene, die Sie im Backend sehen, ist die E-Mail-Verwaltung. Jede E-Mail, die PrestaShop versendet, ist wichtig und wertvoll. Dies kann beispielsweise eine Bestellbestätigung, eine Rechnung, eine E-Mail zum Zurücksetzen Ihres Passworts oder eine Bestätigung Ihrer Newsletter-Anmeldung sein. Für jede dieser E-Mails gibt es je nach Sprache sowohl eine HTML- als auch eine Textdatei. Diese Versionen werden für jede Sprache als separate Dateien gespeichert. Die Dateien befinden sich im Ordner „mails“ Ihrer Installation.

Die Logikschicht besteht aus Code. In PrestaShop ruft PHP-Code im Kern oder in einem Modul die Methode `Mail::Send()` auf . Mit dieser Methode versenden PrestaShop 1.7 und 8.x Transaktions-E-Mails bei bestimmten Ereignissen. Neuere, auf Symfony basierende Administrationsabläufe verwenden ebenfalls diese Methode. Einige Module nutzen zwar eigene E-Mail-Dienste, aber es gibt keinen Dienst, der die `Mail::Send()`-Methode in allen Kernmodulen kapselt. Diese spezielle `Mail::Send() `-Methode steuert die Entscheidung, welche Template-Datei geladen wird, welche Variablen benötigt werden und wer die E-Mail erhält – sei es eine Bestellung, ein Status oder eine Passwortänderung. Änderungen an der Template-Datei wirken sich auf die Ausgabe dieser Logik aus, nicht auf die Logik selbst.

Mail::Send() benötigt die folgenden Parameter:

1. $id_lang
2. $template (Name der Datei, ohne Dateiendung)
3. $Betreff
4. $template_vars (Array mit Variablen zum Ersetzen der Variablen in der Vorlage)
5. $ zu
6. $to_name
7. $von
8. $ from_name 

und andere mögliche Parameter wie $attachment.

Es unterstützt außerdem den SMTP-Modus und erzwingt einen benutzerdefinierten Vorlagenpfad sowie die Angabe von `$id_order`. Bei der Verwendung besteht der größte Aufwand beim Erstellen eines benutzerdefinierten E-Mail-Moduls darin, das `$template_vars`-Array korrekt zu erstellen und sicherzustellen, dass `$template` auf die richtige Datei verweist. Der Aufruf der Methode `Mail::Send()` benötigt in der Regel nicht mehr.

Diese Unterscheidung ist wichtig, da viele Ladenbesitzer dadurch verwirrt werden. Sie sagen: „Ich habe die Vorlage bearbeitet, aber es hat sich nichts geändert“ oder „Wie füge ich eine automatische E-Mail hinzu?“ Diese Probleme entstehen durch die Vermischung der beiden Ebenen.

1.1 Die Template-Ebene in der Praxis

Um das Erscheinungsbild einer Vorlage zu bearbeiten, ist der Backend-Bereich der richtige Ausgangspunkt.

• Klicken Sie auf „Verbessern“ > „International“ > „Übersetzungen“ (dieser Pfad gilt für PrestaShop 1.7 und 8.x, für PrestaShop 1.6 verwenden Sie „Lokalisierung“ > „Übersetzungen“). Wählen Sie „Übersetzungen bearbeiten“ und anschließend „E-Mail-Übersetzungen“ als Übersetzungstyp.

Die Seite „Übersetzungen“ unter „Verbessern > International“

• Wählen Sie aus, ob Sie den Textkörper oder den Betreff bearbeiten möchten.

E-Mail-Übersetzungen mit ausgewähltem Betreff

• Wählen Sie das Design aus, normalerweise Core (kein Design ausgewählt), es sei denn, Sie verwenden ein designspezifisches Override und die Sprache, die Sie bearbeiten möchten.

E-Mail-Übersetzungen sind auf den Textkörper eingestellt, Design und Sprache sind ausgewählt.

• Klicken Sie auf Bearbeiten und wählen Sie die gewünschte E-Mail aus der Liste aus, z. B. die E-Mail zur Kontoerstellung oder die Bestellbestätigung.

Nach dem Klicken auf „Ändern“ wird die Liste der Kern-E-Mails und Modul-E-Mails angezeigt.

Die Liste der Kern-E-Mails wurde erweitert und zeigt nun die einzelnen Vorlagennamen an.

Vollständige Liste der wichtigsten E-Mail-Vorlagen, die zur Übersetzung verfügbar sind

Die ausgewählte Kontovorlage mit den Registerkarten HTML anzeigen / HTML bearbeiten / TXT anzeigen/bearbeiten

Sobald Sie das getan haben, werden Ihnen drei Optionen angezeigt: eine Vorschau der HTML-Version, eine bearbeitbare HTML-Version, mit der Sie zum Quellcode wechseln können, wenn Sie den WYSIWYG-Editor überspringen möchten , und eine Klartextversion.

Ändern Sie die HTML-Version der E-Mail-Nachricht mithilfe des integrierten WYSIWYG-Editors.

Ändern Sie jedes Mal sowohl die HTML- als auch die Textversion, da manche E-Mail-Clients und Nutzer mit deaktivierten Bildern nur die Textversion lesen. Andernfalls erhält die Hälfte Ihrer Empfänger eine E-Mail, die nicht dem von Ihnen erstellten Design entspricht.

TXT-Version der E-Mail-Vorlage für das Konto anzeigen/bearbeiten

Wenn Sie lieber mit Dateien arbeiten, können Sie die gleichen Vorlagen per FTP oder SFTP im Ordner „mails“ abrufen. Der Ordner ist nach Sprachen sortiert. Das Bearbeiten der Datei „account.html“ im Ordner und das anschließende Hochladen führt zum gleichen Ergebnis wie die Bearbeitung im Backend-Editor.

Wir stellen fest, dass das WYSIWYG-Tool keinerlei Sicherheitsvorkehrungen bietet. Jeder noch so kleine Fehler in den Smarty- oder Twig-Tags des Template-Codes führt dazu, dass der Rendering-Prozess fehlschlägt. Meiner Meinung nach ist es daher unerlässlich, alle vorgenommenen Änderungen per FTP auf der Testumgebung Ihres Shops zu testen. Ein oft missverstandener Punkt: Template-Änderungen sind themen- und sprachspezifisch. Wenn Ihr Shop ein benutzerdefiniertes Theme verwendet und Sie „Core (kein Theme ausgewählt)“ bearbeitet haben, verwenden Ihre Live-E-Mails möglicherweise weiterhin die vom Theme selbst überschriebenen Einstellungen. Prüfen Sie daher immer, welches Theme aktiv ist, bevor Sie davon ausgehen, dass eine Änderung nicht wirksam wurde. Dieser Punkt ist für einen Großteil der Supportanfragen verantwortlich, in denen es darum geht, dass Änderungen nicht angezeigt werden. Ein weiterer wichtiger Punkt: Bei PrestaShop 8.x werden E-Mails möglicherweise gar nicht im Übersetzungsbildschirm angezeigt, wenn der Shop das Twig-basierte E-Mail-Theme anstelle des klassischen Template-Systems verwendet. Prüfen Sie daher unter „Verbessern > Design > E-Mail-Theme“ auf eine Übersetzungsoption, bevor Sie davon ausgehen, dass der klassische Bildschirm alle vom Shop versendeten E-Mails enthält. Überprüfen Sie zunächst das Menü in PrestaShop erneut, da PrestaShop den Speicherort der E-Mail-Verarbeitung bei der Aktualisierung auf Symfony ständig ändert.

Wenn ein Design E-Mail-Vorlagen überschreibt, befinden sich diese Dateien im Ordner themes/ /mails/ Das Verzeichnis / entspricht der Ordnerstruktur des Kernverzeichnisses mails/. Für Shops, die dieses Theme verwenden, wird eine Datei namens account.html verwendet, die sich an diesem Ort befindet.

Es handelt sich um denselben Überschreibungsmechanismus, den Themes bereits für Shop-Vorlagen verwenden, nur angewendet auf E-Mails.

Design > E-Mail-Theme in PrestaShop 9.x, mit Anzeige der Optionen „E-Mails generieren“ und „E-Mails übersetzen“ für Twig-basierte E-Mail-Themes

2.0 Häufige Bearbeitungsfehler, die Sie vermeiden sollten

Einige Muster tauchen immer wieder auf, wenn Ladenbesitzer beginnen, Vorlagen selbst anzupassen:

• Es wird nur die HTML-Version bearbeitet. Die Textversion übernimmt Änderungen nicht automatisch, und diese Art von TXT/HTML-Vorlagendesynchronisation nach einem Übersetzungsupdate ist ein häufig gemeldetes Muster im Problem-Tracker von PrestaShop, selbst ohne einen einzigen kanonischen Fehlerbericht, auf den verwiesen wird.
• Das versehentliche Löschen von Template-Variablen kann vorkommen. Tags wie {firstname}, {order_name} oder {id_order} sind Platzhalter und werden vom E-Mail-Generierungsskript beim Versand der E-Mail automatisch befüllt. Wird jedoch der HTML-Code um die Template-Variable herum geändert, kann die Variable ihre Funktion verlieren. Tags funktionieren dann möglicherweise nicht mehr, verschwinden oder erscheinen wortwörtlich in der E-Mail, anstatt aufgelöst zu werden.
• Wenn der Cache nach einer Bearbeitung nicht geleert wird, kann dies zu Problemen führen. PrestaShop generiert Templates, und ein veralteter Cache ist die häufigste Ursache dafür, dass eine bearbeitete und getestete E-Mail nicht angezeigt wird. Sie sollten den Cache im Backend unter „Erweiterte Parameter“ > „Performance“ leeren, da dort der Cache des Smarty-Templates aktualisiert wird. Der Befehl `bin/console cache: clear` leert einen anderen Cache im Symfony-Framework und kann nicht als Ersatz verwendet werden. Dieselbe Regel gilt auch für überschriebene Theme-Templates: Ein Theme, das eigene E-Mail-Templates im Verzeichnis `themes/` bereitstellt, … Der Ordner /mails/ generiert und speichert die E-Mails wie PrestaShop im Cache. Ihre Änderungen werden daher erst angezeigt, wenn Sie auch diesen Cache leeren.
• Die Annahme, dass sich die Bearbeitung der Betreffzeile am selben Ort wie die Bearbeitung des Nachrichtentextes befindet, ist ein Irrtum. Die Betreffzeile ist eine Auswahlliste im Übersetzungsfenster und wird beim ersten Durchsehen leicht übersehen.
• Das Testen im Browser oder im Posteingang kann irreführend sein. Die Backend-Vorschau zeigt die E-Mail innerhalb des CSS-Kontexts des Admin-Themes an. Dies gilt für E-Mail-Clients wie Gmail, Outlook oder Apple Mail, deren CSS-Funktionalität eingeschränkt ist. Was in der Vorschau gut aussieht, kann nach dem Versand der E-Mail zu Problemen führen.
• Nun kommt die zweite Ebene ins Spiel. Sie möchten Ihre Kunden vielleicht informieren, sobald ein nachbestellter Artikel wieder verfügbar ist. Sie könnten eine Benachrichtigung für Ihr Lagerteam einrichten, sobald eine Bestellung als zerbrechlich gekennzeichnet ist. Aktuell gibt es jedoch keine PrestaShop-Vorlage, die diese Funktionen bietet, da es auch keinen entsprechenden Auslöser für diese Vorlage gibt.

Das sind keine ungewöhnlichen Probleme. Vorlagen sind der Grund dafür, dass der Satz „Vorlage bearbeiten, speichern und weitermachen“ oft in eine stundenlange Fehlersuche ausartet.

3.0 Wenn das Bearbeiten einer Vorlage nicht ausreicht

Hier kommt die zweite Ebene ins Spiel. Beispielsweise müssen Sie Ihre Kunden möglicherweise informieren, wenn bestellte Produkte wieder verfügbar sind, obwohl sie zwischenzeitlich nicht auf Lager waren. Oder Sie möchten Ihre Lagerarbeiter benachrichtigen, wenn eine Bestellung zerbrechliche Artikel enthält. PrestaShop bietet keine vordefinierten Nachrichten für solche Benachrichtigungen, da es kein entsprechendes Signal für diese Situationen gibt.

Es handelt sich um ein Logikproblem, nicht um ein Template-Problem. Es muss auf Modulebene gelöst werden.

Das Modulsystem von PrestaShop stellt Hooks und Ereignispunkte im Quellcode bereit, an die Module benutzerdefinierten Code anhängen können, und einige davon werden im Zusammenhang mit Bestell- und Kundenlebenszyklusereignissen ausgelöst (actionOrderStatusUpdate und actionOrderStatusPostUpdate bei Änderungen des Bestellstatus, AktionKundenkontoHinzufügen (z. B. für die Kontoerstellung usw.). Ein Modul, das für die Verarbeitung benutzerdefinierter Transaktions-E-Mails entwickelt wurde, erfüllt typischerweise zwei Funktionen:

1. Es lauscht auf den auslösenden Hook. Bei einer Benachrichtigung über eine Wiederauffüllung des Lagerbestands bedeutet dies beispielsweise, sich in die Aktualisierungen der Lagerbestandsmenge einzuklinken. Bei einer E-Mail zum Bestellstatus bedeutet es, auf den Hook `actionOrderStatusUpdate` zu ​​reagieren, der kurz vor dem Speichern des neuen Status ausgelöst wird, oder auf `actionOrderStatusPostUpdate`, der kurz danach ausgelöst wird. Die beiden Hooks sind nicht austauschbar, da der Code, der sich in den ersten Hook einklinkt, den in der Datenbank gespeicherten neuen Status noch nicht sieht.
2. Aufrufe Mail::Send() mit einer neuen Vorlage. Anstatt eine bestehende Vorlagendatei wiederzuverwenden, definiert eine gut gestaltete benutzerdefinierte E-Mail ihr eigenes HTML/TXT-Paar, das entweder im Modul selbst platziert wird. Mails wird ein Unterordner hinzugefügt oder dem Sprachordner des Shops zugeordnet und übergibt diesem die spezifischen Variablen, die die neue Vorlage benötigt.

PrestaShop bietet verschiedene E-Mail-Hooks, die jeweils einem anderen Zweck dienen. Die Wahl des richtigen Hooks sorgt für ein schlankes Modul und vermeidet unnötige Überschreibungen der Mail-Klasse.

3.1 actionEmailSendBefore

Dies ist die beste Methode, um die Hauptdaten einer E-Mail vor dem Versand zu ändern. Sie funktioniert mit Empfänger, Betreff und Vorlagenvariablen und ermöglicht es Ihnen, den Versand der E-Mail vollständig zu verhindern.

Verwenden Sie es immer dann, wenn Ihre Anforderung den Inhalt der E-Mail betrifft und nicht das endgültige Aussehen des E-Mail-Textes.

Beispiel: Ändern Sie den Empfänger und den Betreff.

public function hookActionEmailSendBefore($params)
{
    // E-Mail-Weiterleitung während des Testens
    $params['to'] = '[E-Mail geschützt] ';

    // Betreff aktualisieren
    $params['subject'] = '[TEST] ' . $params['subject'];
}

Beispiel: Bedingte Stornierung einer E-Mail

public function hookActionEmailSendBefore($params)
{
    if ($params['template'] === 'order_conf') {
        return false; // Diese E-Mail wird nicht mehr gesendet
    }
}

3.2 AktionEmailAddBeforeContent

Verwenden Sie diesen Hook, wenn Sie lediglich Inhalte vor dem generierten HTML- oder TXT-E-Mail-Text einfügen möchten. Er eignet sich gut für Hinweise, die am Anfang vieler Transaktions-E-Mails erscheinen sollen. Die ursprüngliche E-Mail-Vorlage bleibt dabei unverändert.

Die ursprüngliche E-Mail-Vorlage bleibt unverändert.

Beispiel: Fügen Sie einen Hinweis über dem E-Mail-Inhalt hinzu.

public function hookActionEmailAddBeforeContent($params)
{
    zurückkehren ' Wichtig: Bitte bewahren Sie diese E-Mail für Ihre Unterlagen auf. ';
}

3.3 actionEmailAddAfterContent

Dieser Hook funktioniert ähnlich wie der vorherige, nur dass der Inhalt nach dem generierten E-Mail-Text angehängt wird.

Nutzen Sie es für Informationen, die natürlicherweise in den Fußbereich gehören.

Beispiel: Supportinformationen anhängen

public function hookActionEmailAddAfterContent($params)
{
    zurückkehren '
    Benötigen Sie Hilfe? Kontaktieren Sie jederzeit unser Support-Team. ';
}

3.4 actionMailAlterMessageBeforeSend

Dieser Hook ist für erweiterte Anpassungen gedacht. Anstatt Vorlagendaten zu ändern, ermöglicht er den Zugriff auf das endgültige Nachrichtenobjekt unmittelbar vor der Zustellung.

Wählen Sie diesen Hook, wenn Ihre Anforderung das Mail-Objekt selbst und nicht den Vorlageninhalt betrifft.

Beispiel: Hinzufügen eines benutzerdefinierten E-Mail-Headers

public function hookActionMailAlterMessageBeforeSend($params)
{
    /** @var \Symfony\Component\Mime\Email $message */
    $message = $params['message'];

    $message>getHeaders()>addTextHeader(
        'XModuleSource',
        'Mein benutzerdefiniertes Modul'
    );
}

3.5 Kurzer Entscheidungsleitfaden

Als praktische Regel gilt: Beginnen Sie für die Geschäftslogik immer mit `actionEmailSendBefore` , verwenden Sie die Content-Hooks für einfaches Einfügen des Nachrichtentextes und reservieren Sie `actionMailAlterMessageBeforeSend` für erweiterte Anpassungen auf Nachrichtenebene. So bleibt Ihr Modul mit dem PrestaShop-Kern-E-Mail-System kompatibel, ohne dass Überschreibungen erforderlich sind.

Für Fälle, die die oben genannten nativen Hooks nicht abdecken, gehen einige Drittanbietermodule noch einen Schritt weiter: Anstatt dass jedes Modul die PrestaShop-Kernklasse ` Mail` separat überschreibt , führt ein Modul wie `prestashopmailhook` diese Überschreibung einmalig durch und stellt sie als eigenen Hook `actionMailSend` bereit. Dieser Hook wird weiterhin jedes Mal ausgelöst, wenn eine E-Mail über das System versendet wird, unabhängig vom Erfolg. Es ist wichtig zu verstehen, dass dies immer noch eine Überschreibung der Kernklasse `Mail` darstellt und somit das oben beschriebene Risiko von Aktualisierungsproblemen birgt. Der eigentliche Vorteil besteht darin, dass andere Module eine E-Mail-Nachricht untersuchen oder ändern, das sendende Backend wechseln, benutzerdefinierte Variablen hinzufügen oder eine Nachricht unter bestimmten Bedingungen unterdrücken können – alles durch Reaktion auf denselben Hook, anstatt dass jedes Modul `Mail` unabhängig überschreibt. Genau dies führt dazu, dass Module um dieselbe Datei konkurrieren. Bevor Sie ein solches Modul installieren, überprüfen Sie dessen `ps_versions_compliancy` mit Ihrer PrestaShop-Version, da eine nicht gewartete `Mail`-Überschreibung genau die Art von Überschreibung ist, vor der dieser Artikel warnt.

3.6 Ein praktisches Beispiel: Bestellstatus-ausgelöste benutzerdefinierte E-Mail

Angenommen, Sie möchten einem Kunden eine personalisierte „Dankeschön-Nachricht mit Pflegehinweisen“ per E-Mail senden, wenn eine Bestellung, die einer bestimmten Produktkategorie zugeordnet ist, versendet wird – etwas, das die Standard-Versandbestätigungsvorlage nicht leisten kann, da sie keine Produktkategorien berücksichtigt.

Die praktische Ausgestaltung dieser Lösung sieht folgendermaßen aus:

• Ein kleines, benutzerdefiniertes Modul registriert sich auf dem actionOrderStatusUpdate (oder actionOrderStatusPostUpdate) Haken.
• Innerhalb der Hook-Methode prüft das Modul, ob die Bestellung ein Produkt aus der entsprechenden Kategorie enthält und verfolgt, welche Bestellungen bereits per E-Mail benachrichtigt wurden. Denn dieser Hook kann bei einigen Abläufen für denselben Statusübergang mehr als einmal ausgelöst werden, und wenn ein Kunde zweimal dasselbe „Danke“ erhält, wird dies als Fehler interpretiert.
• Wenn eine Übereinstimmung vorliegt, lädt das Modul sein eigenes Template-Paar (nicht das Kern-Versandtemplate) und ruft die E-Mail-Versandmethode mit den bestellungsspezifischen Variablen Kundenname, Produktname und Tracking-Link auf. Dabei werden alle vom Kunden angegebenen Werte maskiert, bevor sie im HTML-Template erscheinen, da eine nicht maskierte Variable eine echte Öffnung für die Einschleusung gespeicherter Inhalte darstellt.
• Die Hauptversandbestätigungs-E-Mail wird wie gewohnt verschickt; dies ist eine zusätzliche E-Mail.

Dies ist etwas ganz anderes als die Änderung der Versandvorlage, denn durch die Änderung dieser Vorlage würde die Nachricht an alle versendeten Bestellungen gesendet, nicht nur an die, die Sie wünschen.

Das Knowband -Modul für Treuepunkte (kbloyaltypoints) ist ein praktisches Beispiel für genau dieses Vorgehen. Es registriert sich bei der Aktion „Bestellstatusaktualisierung“ und jede konfigurierte Treueregel definiert ihre eigene Bedingung (z. B. einen Mindestbestellwert) sowie eine eigene Benachrichtigungs-E-Mail. Ändert sich der Status einer Bestellung auf einen der in den allgemeinen Einstellungen des Moduls konfigurierten Status („gutgeschrieben“ oder „storniert“), wird der entsprechende Hook ausgelöst, prüft die Bestellung anhand der passenden Regel und versendet, falls zutreffend, die zugehörige Benachrichtigungs-E-Mail (erstellt mit der Betreffzeile und dem WYSIWYG-Editor des Moduls, nicht mit der Standardvorlage für den Bestellstatus), um den Kunden über die Gutschrift oder Stornierung seiner Treuepunkte zu informieren.

Modul „Treuepunkte“ – Allgemeine Einstellungen: Hier werden die Bestellstatus konfiguriert, die die Gutschrift/Stornierung von Punkten auslösen.

Die Vorlage für die Registerkarte „Benachrichtigungen“ der Regel ist die tatsächliche E-Mail, die an den Kunden gesendet wird, wenn der Bestellstatus-Hook seine Treuepunkte gutschreibt.

Was der Kunde tatsächlich in seinem Posteingang erhält, sobald der Hook ausgelöst wird und die Benachrichtigungs-E-Mail der Regel versendet wird.

Das Modul selbst finden Sie hier: Knowband-Treuepunkte-Modul

4.0 Die richtige Vorgehensweise auswählen

Bevor Sie mit den Anpassungsarbeiten beginnen, sollten Sie eine kurze Entscheidungsprüfung durchführen:

• Sie möchten lediglich den Text, die Farben oder ein Logo in einer bestehenden E-Mail ändern? Bleiben Sie im Übersetzungsbereich. Es sind keine Programmierkenntnisse erforderlich.
• Willst du dasSoll Ihre E-Mail ein deutlich anderes Aussehen bekommen – ein neues Layout, eine andere Struktur, ein markenkonformes Design für jede Transaktions-E-Mail? Bearbeiten Sie zwar weiterhin Vorlagendateien, planen Sie aber, das HTML/TXT-Paar grundlegend neu zu gestalten (idealerweise tabellenbasiertes HTML für die Kompatibilität mit E-Mail-Clients), anstatt die Standardvorlage Stück für Stück anzupassen.
• Sie möchten eine neue E-Mail erstellen, die noch nicht existiert, oder eine bestehende E-Mail unter neuen Bedingungen versenden? Dafür benötigen Sie ein Modul mit Hook-Logik; die Template-Ebene allein reicht nicht aus.
• Sie verwalten viele Vorlagen für verschiedene Shops oder Sprachen und möchten nicht jede einzelne manuell bearbeiten? Hier kommt ein Ein dediziertes Modul zur Verwaltung von E-Mail-Vorlagen oder ein vorgefertigtes Vorlagenpaket rechtfertigt seinen Preis, da es typischerweise die Synchronisierung mehrerer Shops und Sprachen übernimmt, was mit dem Standardbildschirm mühsam ist. 
• Etwas Wiederverwendbares für verschiedene Projekte entwickeln, wie beispielsweise eine gemeinsame Bibliothek für Transaktions-E-Mail-Logik? Das spricht dafür, eher ein kleines internes SDK oder eine Hilfsbibliothek zu schreiben, anstatt bestehende Strukturen zu duplizieren. Mail::Send() Aufrufe über mehrere Module hinweg.

5.0 Eine kurze Checkliste vor dem Verkaufsstart

Bevor Sie E-Mail-Personalisierungen veröffentlichen, sollten Sie Folgendes durchgehen:

• Sowohl die HTML- als auch die TXT-Version wurden aktualisiert und gespeichert.
• Das richtige Design wurde beim Bearbeiten ausgewählt (nicht standardmäßig nur „Core“).
• Alle Template-Variablen sind intakt und werden in einem Test korrekt gerendert.
• Der Cache wurde nach der Bearbeitung geleert.
• Testversand in mindestens zwei echten Posteingängen geprüft (nicht nur in der Administratorvorschau).
• Betreffzeile separat bearbeiten, falls erforderlich.
• Für benutzerdefinierte Logik: Der Hook wird nur unter der vorgesehenen Bedingung ausgelöst, nicht bei jeder Bestellung. 
• Die SMTP-Einstellungen wurden unter „Erweiterte Parameter > E-Mail“ überprüft, der Test verschleiert also kein Zustellungsproblem.

Ein wichtiger Punkt, den man gesondert erwähnen sollte: Das E-Mail-Protokoll von PrestaShop protokolliert zwar den Aufruf von `Mail::Send()` und die Weiterleitung der Nachricht, dies beweist aber nicht, dass die Nachricht tatsächlich im Posteingang angekommen ist. Falsche SMTP-Host-, Port- oder Zugangsdaten unter „Erweiterte Einstellungen > E-Mail“ führen dazu, dass in diesem Protokoll zwar der Versand dieser E-Mails angezeigt wird, aber tatsächlich keine Nachricht den Server verlassen hat. Überprüfen Sie daher nach jeder Änderung der E-Mail-Server-Einstellungen immer die tatsächliche Zustellung der E-Mails in einem realen Posteingang.

6.0 Die Grundlagen schaffen

Transaktions-E-Mails sind viel wichtiger, als die meisten Shop-Betreiber annehmen. Sie gehören zu den wenigen Korrespondenzformen, die Kunden tatsächlich lesen, da sie ihre Bestell- oder Kontodaten erwarten. Eine unpersönliche Standard-E-Mail-Vorlage trägt nicht dazu bei, das Vertrauen dieser Kunden zu erhalten. Die Lösung liegt jedoch nicht immer in der HTML-Bearbeitung. Manchmal benötigen Übersetzungen nur eine kleine Anpassung, und manchmal muss das Modul wissen, wann diese E-Mail überhaupt generiert werden soll.

Wenn Sie gerade erst mit Ihrem Projekt begonnen haben, sollten Sie nicht versuchen, zwei Dinge gleichzeitig zu tun. Zuerst sollten Sie Ihre Templates korrigieren, da dies Ihrem Shop ein professionelles Aussehen verleiht. Anschließend können Sie, falls erforderlich, wie oben erwähnt, benutzerdefinierte, logikbasierte Hooks erstellen. 

7.0 Die Kurzfassung

Jede PrestaShop-E-Mail birgt zwei Probleme: ihr Aussehen und den Zeitpunkt des Versands. Die Bearbeitung einer Vorlage löst jedoch nur das erste Problem.

Kosmetische Änderungen gehören in den Übersetzungsbereich – dafür ist kein Code erforderlich. Eine komplett neue Benachrichtigung oder eine bestehende E-Mail, die unter neuen Bedingungen ausgelöst werden soll, benötigt ein Modul, das sich in ein PrestaShop-Ereignis einklinkt und die Funktion `Mail::Send()` aufruft.

Bevor ein vollständiges Modul erstellt werden kann, können die eigenen E-Mail-Hooks von PrestaShop, actionEmailSendBefore und ähnliche Funktionen, bereits jetzt einen Sendevorgang umschreiben, erweitern oder abbrechen, ohne dass eine Überschreibung der Mail-Klasse erforderlich ist.

Noch etwas Wichtiges: Ein Eintrag „gesendet“ im E-Mail-Protokoll bedeutet lediglich, dass die Funktion Mail::Send() aufgerufen wurde, nicht aber, dass die Nachricht tatsächlich im Posteingang angekommen ist. Überprüfen Sie daher immer den tatsächlichen Empfang.

Danke fürs Lesen.