Newsletter werden zwar prinzipiell in HTML gebaut und mit CSS gestaltet, allerdings werden diese von den unterschiedlichen Mail-Clients recht unterschiedlich gerendert.
Um eine möglichst große Kompatibilität zu erreichen, kann man deshalb leider nicht alle Möglichkeiten von HTML5 und CSS3 ausschöpfen.
Auch die responsive Darstellung ist bei manchen Clients nicht möglich, da diese keine Media Queries unterstützen oder teilweise fix vorgegebene Breiten benötigen.
Bei frisch installierten Newslettern wird eine richtig aufgebaute Index.html bereits angelegt.
Hier sind bereits alle notwendigen Voraussetzungen erfüllt. Allerdings müssen natürlich bei Anpassung der Schriftstile, Verwendung anderer Schriftarten und der Anpassung des Templates die allgemeinen CSS-Styles und die Media Queries dementsprechend geändert oder ergänzt werden.
Um die maximale Kompatibilität und den vollen Umfang der Funtkionen des Bakehouse zu garantieren, sind bestimmte Voraussetzungen - manchmal auch in der richtigen Reihenfolge - einzuhalten.
So werden an manchen Stellen spezielle Conditions benötigt, die den umschlossenen Code nur für bestimmte Clients relevant machen.
Diese können wir folgt aussehen:
Diese Conditions werden meistens durch die Verwendung der Newsletter-ViewHelper automatisch gesetzt, sie werden aber auch für die allgemeinen CSS-Styles und Media Queries, die zu Beginn der Index.html gesetzt werden, benötigt.
Um eine Vorstellung zu bekommen, was in der Index.html-Datei benötigt wird und wie diese aufgebaut sein muss, sehen wir uns zunächst ein vereinfachtes, exemplarisches Beispiel an:
Gehen wir nun das HTML von oben nach unten durch und sehen uns die einzelnen Teile genauer an:
Zu Beginn müssen wir natürlich die richtigen Namespaces setzen. Für jeden Newsletter benötigen wir den Namespace des Bakehouse und natürlich der Newsletter-Erweiterung. Sollen im Newsletter auch die News- oder Booking-Erweiterungen ausgegeben werden, müssen natürlich auch diese Namespaces aufgeführt werden.
Als nächstes folgt der preHeader-ViewHelper. Dieser liest die SEO-Description der Newsletter-Seite aus und gibt sie als unsichtbaren Text am Beginn des Newsletters aus. Da die meisten Mail-Clients neben dem Betreff einer Mail auch einen Teil des ersten Textes als Vorschau anzeigen, kann so durch Befüllung der SEO-Description Einfluss auf dieses Verhalten genommen werden.
Im nächsten Block finden wir 2 Outlook-Conditions, in denen die Schriftstile definiert werden. Außerdem finden sich hier CSS-Styles, die für das allgemeine Template benötigt werden.
Nun folgt ein CSS-Block, der allgemeine CSS-Styles für alle "nicht Outlook"-Clients bereithält. Hier müssen gegebenenfalls auch die Schriftstile ergänzt oder angepasst werden.
Die nächste Condition wird wieder für das allgemeine Template benötigt.
Der nun folgende <f:render ... wird nur benötigt, wenn im Template die Elemente aus dem Bakehouse-Core verwendet werden. Dieser rendert die Media Queries für die verwendeten Contentelemente. Genauere Informationen zur Verwendung der Core-Elemente
Die nächsten 2 Blöcke beinhalten die Mediaqueries für die Anzeige auf Devices, deren Displaybreite größer als 480px oder eben kleiner als 480px ist. Hier können alle Styles ergänzt werden, die durch Anpassung des Templates und der Styles der Core-Elemente benötigt werden.
Nun folgt der sichtbare Teil des Templates, also die Grundstruktur, die immer gleich bleibt - Header, Footer und die Contentbereiche.
Zum Schluss folgt ein img-Tag, der für das Tracking benötigt wird.
Vor dem Go-Live sollte hier sichergestellt werden, dass die richtige Piwik-ID und auch die richtige URL mitgegeben werden!
Sehen wir uns nun den sichtbaren Teil des Templates an.
Beginnen wir mit einem exemplarischen Beispiel. Im folgenden Code haben wir einen Header mit dem Logo und dann 2 Contentbereiche.
Da wir im Newsletter beim Layouting nicht mit Flexbox und ähnlichen Layout-Techniken arbeiten können, muss hier auf die Verwendung der ViewHelper und des altbewährten table Elements zurückgegriffen werden.
Jeglicher Content, der hardcoded im Template ist, sollte immer innerhalb eines Section-ViewHelpers und einem Row- und einem Col-ViewHelper liegen!
Da die Elemente ebenfalls mit den ViewHelpern aufgebaut sind, müssen die Contentbereiche ohne Breitenbeschränkung nur von einem div Element/Container umschlossen im Template liegen.
Die Namen der Contentbereiche müssen immer wie folgt genannt werden:
Beim Verschicken des Newsletters werden HTML und CSS gemergt. Das erhöht die Darstellungsqualität bei schlechteren Mail-Clients. Dabei werden alle im Newsletter inkludierten CSS-Dateien ausgelesen und als inline-CSS direkt in das HTML geschrieben.
Das bedeudet, dass das Styling mit CSS prinzipiell in der CSS-Datei des Templates erfolgen kann. Da das endgültig gerenderte HTML aber durchaus komplex mit zahlreichen Verschalchtelungen sein kann, ist es manchmal einfacher die Styles im Template selbst direkt inline zu setzen.
Da viele Clients (vor allem ältere Outlook-Varianten) weder Media Queries noch CSS, das nicht inline ist, interpretieren können, muss der Newsletter ohne Einsatz der Media Queries als Desktopversion mit fixer Breite funktionieren. Das bedeutet, dass die Mobileversion immer als Erweiterung durch die Media Queries gedacht werden muss.
Da das CSS der Desktopvariante als inline-CSS im HTML steht, müssen die Media Queries entweder mit stärkerer Definition oder mit !important gesetzt werden.
Leider können einige Techniken, die man gewohnt ist, aufgrund mancher Clients nicht verwendet werden. Im Folgenden eine kurze Aufzählung:
Alle Links müssen absolut sein!
Bei den Link-ViewHelpern kann hierfür absolute="true" mitgegeben werden.
Mit folgenden Placeholdern können Mappings zu Feldern des Empfänger:innen-Kontaktes hergestellt werden. Beim Versenden des Newsletters wird der Tag automatisch mit dem entsprechenden Wert überschrieben.
| Placeholder | Beschreibung |
| ###ANREDE### | Personalisierte Anrede (so wie im Interface definiert) |
| ###FIRSTNAME### | Vorname |
| ###LASTNAME### | Nachname |
| ###NAME### | Name |
| ###TITEL### | Titel |
| ###EMAIL### | E-Mail-Adresse |
| ###BESCHREIBUNG### | Beschreibung |
| ###DOUBLEOPTINLINK### | Link um das Double Opt-In zu bestätigen |
| ###UNIQID### | Eindeutige ID basierend auf Microtime (php: uniqid) |
Folgende Felder können auch base64 Codiert abgefragt werden:
| Placeholder | Beschreibung |
| ###FIRSTNAMEBASE64### | Vorname |
| ###LASTNAMEBASE64### | Nachname |
| ###NAMEBASE64### | Name |
| ###TITELBASE64### | Titel |
| ###EMAILBASE64### | E-Mail-Adresse |
| ###BESCHREIBUNGBASE64### | Beschreibung |
Eine Sache, die auch einen noch so gut programmierten Newsletter leider zerstören kann, ist das Verhalten des Gmail Webclients. Dieser hat ein Limit an Zeichen, die angezeigt werden. Wird dieses Limit überschritten, so schneidet Google den Newsletter einfach ab - ohne Rücksicht auf HTML-Tags. Daher kann es passieren, dass im Gmail Webclient ein Newsletter komplett falsch dargestellt wird. Es ist somit nie von Nachteil, bei der gesamten Programmierung auf die Länge des Codes zu achten.
Auch der Spam-Score sollte beim Newsletter nicht vergessen werden! Dieser kann bereits vom/von der Integrator:in positiv oder auch negativ beeinflusst werden.
Folgende Punkte verschlechtern den Spam-Score:
...das Wichtigste ist Testen, Testen, Testen - am besten auf so vielen unterschiedlichen Clients wie möglich!