Nach einem WooCommerce-Update stehen Shopbetreiber oft vor einem Dilemma: Entweder übernehmen sie das neue Standard-Template und verlieren ihr individuelles Design, oder sie behalten das bestehende Override und riskieren technische Fehler durch unbemerkte Core-Änderungen. Am besten starten Sie mit einer freigegebenen Designreferenz in Migma und lassen das Template anschließend im Code durch die zuständige Entwicklung abgleichen. Ein reiner Design-Export nimmt Ihnen diese technische Wartung nicht ab.
Das Ziel: ein aktuelles Template, das Bestelldaten korrekt darstellt und optisch nahtlos zum Shop passt. Eine verschwundene Warnmeldung im Backend, ein sauberer Screenshot und die tatsächliche Zustellung im Posteingang sind drei voneinander getrennte Prüfungen. Diese Anleitung beschreibt einen gemeinsamen Abnahmeprozess für Marketing und Entwicklung.
Veröffentlicht von Migma. Technische Angaben geprüft am 19. Oktober 2026. Dieser Leitfaden ist eine redaktionelle Empfehlung und beschreibt keinen nativen Template-Installer von Migma für WooCommerce.
Prüfen, welches Template tatsächlich betroffen ist
Bitten Sie das Shop-Team, unter WooCommerce → Status → Systemstatus nachzusehen. Der offizielle Leitfaden für veraltete Templates beschreibt, wie dieser Bericht vom Theme oder Child-Theme überschriebene Vorlagen auflistet und veraltete Dateien markiert.
Dokumentieren Sie die genaue Datei und die Meldung. Ein Override für Transaktions-E-Mails verhält sich anders als ein Template für Produktseiten – auch wenn beide im selben Bericht auftauchen. Notieren Sie zudem das aktive Theme, relevante E-Mail-Plugins sowie die geprüfte WooCommerce-Version. Starten Sie kein Redesign allein auf Basis des Warntexts.
Klären Sie, wer für die Datei verantwortlich ist: Stammt das Update vom Theme-Hersteller oder liegt eine individuelle Datei im Child-Theme vor, bei der eigene Anpassungen manuell in die aktuelle Version überführt werden müssen? Die WooCommerce-Dokumentation unterscheidet ausdrücklich zwischen diesen beiden Fällen. Wählen Sie den Weg, der zur tatsächlichen Code-Zuständigkeit passt, statt pauschale Anleitungen direkt auf der Produktivumgebung auszuführen.
Vorab zwei Referenzen sichern
Erstellen Sie ein Backup des funktionierenden Templates und sichern Sie ein reales Beispiel einer bereits zugestellten E-Mail. Die Template-Datei bewahrt die technische Implementierung; die zugestellte E-Mail zeigt das tatsächliche Kundenerlebnis. Keines von beiden ersetzt das andere.
Halten Sie bewusste Anpassungen kurz schriftlich fest: Platzierung des Logos, Lesereihenfolge, Support-Texte, Footer-Inhalte und bedingte Abschnitte (Conditional Blocks). Trennen Sie diese gewollten Vorgaben von zufälligen Darstellungsfehlern alter Layouts – ein Zeilenumbruch aus einem veralteten Template muss nicht zwingend erhalten bleiben.
Hinterlegen Sie in Migma eine freigegebene visuelle Referenz für das Zielergebnis. Wenn das Originaldesign bereits dort gepflegt wird, markieren Sie die genaue Vorlage. Falls nicht, erstellen Sie einen Entwurf auf Basis der freigegebenen Texte und CI-Vorgaben. Nutzen Sie realistische Beispieldaten, damit das Mockup nicht fälschlicherweise als Quelle für Live-Transaktionsdaten missverstanden wird.
Implementierung und Design getrennt abgleichen
Der offizielle WooCommerce-Prozess sieht vor: veraltete Templates identifizieren, Backups sichern, von der aktuellen Standardversion ausgehen und individuelle Änderungen gezielt nachtragen. Die Entwicklung sollte die Code-Unterschiede im Detail prüfen und das Template über den regulären Deployment-Prozess des Shops einspielen.
Vermeiden Sie es, lediglich die Versionsnummer im Dateikopf hochzusetzen, um die Warnung zum Verschwinden zu bringen, ohne den Code geprüft zu haben. Es geht darum, funktionale Änderungen im Core zu verstehen und korrekt zu integrieren. Genauso wenig sollte ein PHP-Template einfach durch reines HTML aus einem Design-Download ersetzt werden – Hooks, dynamische Variablen und bedingte Logiken gingen dabei verloren.
Migmas Export-Dokumentation erläutert, wie Sie HTML für Drittsysteme exportieren und am Zielort überprüfen. Nutzen Sie diesen HTML-Code als visuelle Vorlage für die Implementierung. Wie die Bestelldaten letztlich in die Nachricht einfließen, steuern weiterhin die WooCommerce-Templates und Extensions.
Abnahmekriterien an komplexen Bestellszenarien ausrichten
Eine einzelne, perfekte Vorschau reicht als Abnahme nicht aus. Definieren Sie vorab einige repräsentative Testfälle gemeinsam mit dem Entwicklungsteam. Konzentrieren Sie sich dabei auf den eigentlichen Zweck der Benachrichtigung, statt jede Sonderfunktion des Shops in eine einzige E-Mail zu packen.
| Beispielfall | Worauf beim Review zu achten ist |
|---|---|
| Mehrere Artikel mit langen Namen | Produktbezeichnungen bleiben gut lesbar, Summen sind sofort auffindbar |
| Fehlende optionale Kundendaten | Keine leeren Platzhalter oder unpassenden Anreden |
| Rabatte und Versandkosten | Nachricht spiegelt die berechneten Werte des Shops exakt wider |
| Relevanter Statuswechsel der Bestellung | Überschrift und Handlungsaufforderung (Next Steps) passen genau zum Status |
| Kleiner Bildschirm und blockierte Bilder | Kerninformationen zur Bestellung und Support-Kontakt bleiben verständlich |
Diese Szenarien sind empfohlene Prüffälle, keine Testergebnisse. Verändern Sie niemals echte Bestelldaten, nur um das Layout optisch aufzuhübschen. Enthält eine Benachrichtigung bestimmte Felder technisch nicht, streichen Sie den Testfall, statt hypothetische Shop-Funktionen zu erfinden.
Umgesetztes Template mit dem freigegebenen Entwurf abgleichen
Führen Sie vorab Migma Email Preflight auf dem Design-Entwurf aus, um Layout, Links, Wording und typische Versandrisiken zu prüfen. Testen Sie die fertige WooCommerce-Nachricht anschließend separat über die etablierten Testläufe Ihres Teams.
Prüfen Sie zuerst die inhaltliche Richtigkeit: Zweck der Benachrichtigung, Darstellung von Kundennamen, Bestellnummer, Artikelpositionen, Gesamtsummen und Kontaktwege zum Kundenservice. Vergleichen Sie danach die Gestaltung: Logo, Abstände, Kontraste, Schrifthierarchie und Lesbarkeit der Buttons. Kleine optische Abweichungen sind oft vertretbar – geänderte Zusagen zu Zahlung oder Versand müssen hingegen zwingend fachlich geklärt werden.
Testen Sie das Resultat mit echten Test-E-Mails in den gängigen E-Mail-Clients. Eine Browser-Vorschau zeigt nicht verlässlich, wie E-Mail-Clients die Nachricht rendern, und ein Preflight-Check garantiert keine Zustellung im Posteingang. Dokumentieren Sie die Freigabe zusammen mit der zugehörigen Code-Version.
Zukünftige Updates systematisch vereinfachen
Dokumentieren Sie Anpassungen direkt dort, wo auch die Wartungshinweise für das Template liegen: Wer verantwortet den Code, wer gibt Kundentexte frei, wo liegt die Migma-Designreferenz und welche Testfälle wurden abgenommen? Eine Übergabe sollte nie nur aus einem Chat-Screenshot bestehen.
Prüfen Sie bei größeren Updates, ob das neue Standard-Template von WooCommerce mit den bordeigenen Einstellungen Ihren Anforderungen bereits genügt und das Child-Theme-Override vielleicht überflüssig geworden ist. Diese Entscheidung treffen Shopbetreiber und Entwicklung gemeinsam auf Basis der Designanforderungen.
Für grundlegende Überarbeitungen bietet der Leitfaden für das Review von WooCommerce-Bestell-E-Mails weiterführende Hinweise. Bei einem Update bleibt das Ziel fokussiert: Template-Änderungen sauber integrieren, CI-Entscheidungen beibehalten und die finale Kunden-E-Mail vor dem Go-live verlässlich freigeben.
Häufig gestellte Fragen
Aktualisiert Migma WooCommerce-Overrides automatisch?
Nein, dafür gibt es keinen automatisierten Workflow. Migma liefert die freigegebene Designreferenz und bei Bedarf den HTML-Export; die technische Anpassung des Templates und dessen Verhalten liegen bei der WooCommerce-Entwicklung.
Reicht es aus, nur die Versionsnummer im Template-Header anzupassen?
Nein. Das Hochsetzen der Versionsnummer belegt nicht, dass technische Änderungen im Core geprüft wurden. Die Entwicklung sollte das aktuelle Template mit den gewünschten Anpassungen abgleichen und die resultierende E-Mail testen.
Was sollte vor dem Update eines E-Mail-Templates gesichert werden?
Sichern Sie ein Backup des funktionierenden Codes, ein reales Beispiel einer zugestellten E-Mail, eine Übersicht aller bewussten Anpassungen sowie die freigegebene Designreferenz. Halten Sie für alles die zuständige Person und Version fest.
Reicht eine korrekte Browser-Vorschau für die Freigabe aus?
Nein. Prüfen Sie typische Bestelldaten und Bedingungen direkt im fertig implementierten Template und testen Sie die tatsächliche Zustellung über den gewohnten Testprozess Ihres Teams. Eine reine Vorschau garantiert kein fehlerfreies Verhalten in realen Postfächern.