
Auf einen Blick
- ✓JTL-Shop 5.6.0 bereitet Smarty 5 vor (Parallelbetrieb mit Smarty 4), bringt eine vollständige Mailqueue im Backend und unterstützt AVIF als Bildformat für schnellere Core Web Vitals. Wir sehen den technischen Kern der Version klar in der Entwickler-Vorbereitung für 5.7.
- ✓Der wichtigste Breaking Change: die Datei `class_aliases.php` wurde entfernt. Plugins die sich auf veraltete Klassen-Aliase verlassen, werfen nach dem Update Fehler. Vor dem Update alle aktiven Plugins prüfen.
- ✓Wir empfehlen heute den Sprung direkt auf JTL-Shop 5.7 statt auf 5.6 — die 5.7er Version fasst die 5.6er Änderungen zusammen und bringt zusätzliche Neuerungen. Als Vlarom E-Commerce Agentur setzen wir das Update standardmäßig auf einer Testumgebung auf.
Wir pflegen diesen Beitrag bewusst als Versionsarchiv — auch wenn die aktuelle Shop-Version inzwischen 5.7 heißt. Händler die noch auf 5.5 oder 5.6 laufen, brauchen Klarheit über den Sprung, den sie machen. Für alle neuen Projekte richten wir den Shop direkt auf 5.7 ein.
Was JTL-Shop 5.6.0 in Zahlen gebracht hat
Die Version hat drei harte technische Kennzahlen geliefert, die für Händler und Entwickler relevant sind. Aus unseren Projekten sehen wir immer wieder die gleichen Engpässe — 5.6.0 hat bei zweien davon spürbar nachgezogen.
Praxiswerte aus unseren Projekten: Bei einem Shop mit rund 8.000 Produktbildern senkt die Umstellung auf AVIF die Gesamt-Bildlast um etwa 30-40 Prozent gegenüber WebP — ohne sichtbaren Qualitätsverlust. Das schlägt sich direkt im LCP-Wert der Core Web Vitals nieder.
Diese drei Neuerungen sind die wichtigsten Zahlen-Änderungen in JTL-Shop 5.6.0:
- →Smarty 4 und Smarty 5 parallel: Bisher nur Smarty 4. Mit 5.6.0 läuft Smarty 5 parallel — Entwickler und Agenturen können Templates und Plugins rechtzeitig vor der 5.7-Umstellung testen.
- →AVIF als drittes Bildformat: Neben JPEG/PNG und WebP ist AVIF der neue Standard. Dateigröße bei gleicher Qualität 20-40 % kleiner als WebP — messbarer LCP-Gewinn in den Core Web Vitals.
- →Mailqueue mit vollständigem Logbuch: Vorher: Serverlogs durchsuchen oder SMTP-Dienstleister anfragen. Jetzt: alle Transaktions-Mails direkt im Shop-Backend einsehbar inkl. Status, Retry und Fehlermeldung.
Die zentrale Regel bei der 5.6-Planung: Für neue Projekte direkt auf 5.7 gehen. Ein Zwischenschritt über 5.6 lohnt fast nie — außer wenn ein zwingendes Plugin nur auf 5.6 portiert wurde.
Worauf beim Update auf JTL-Shop 5.6 oder 5.7 zu achten ist
Zwei Fallstricke sehen wir bei fast jedem JTL-Shop-Update in Kundenprojekten — sie gelten für 5.6 wie für 5.7:
Was 5.6.0 in der Praxis bei Händlern verbessert hat
Die Lektion
Unsere Erkenntnis aus mehreren Update-Projekten: Viele 5.6.0-Funktionen sind in 5.7 geblieben oder wurden erweitert. Wer heute updatet, überspringt 5.6 und geht direkt auf 5.7 — die Investition in ein 5.6-Zwischenupdate lohnt nur in Sonderfällen (z.B. bei sehr alten individuellen Plugins, die auf 5.7 noch nicht portiert sind).
JTL-Shop-Update in 5 Schritten sauber durchziehen
So läuft ein sauberes Shop-Update in unserer Praxis ab — von der Vorbereitung bis zum Go-Live. Die Reihenfolge ist bei 5.6 und 5.7 identisch:
Schritt 1: Bestandsaufnahme Plugins und Templates
Vollständige Liste aller aktiven Plugins und Template-Anpassungen erstellen. Pro Eintrag: Hersteller, Version und Smarty-Kompatibilität prüfen. Häufigster Fehler: individuelle Templates werden in der Bestandsaufnahme vergessen, weil sie nicht im Plugin-Manager stehen.
Schritt 2: Testumgebung aufsetzen
Eine Kopie des Live-Shops auf einem separaten Server oder einer Test-Domain anlegen. Datenbank duplizieren, Daten aus `/uploads/` kopieren, Konfiguration anpassen (`shop.eigenedomain.test`). Ohne Testumgebung kein Update — das ist nicht verhandelbar.
Schritt 3: Update auf Testumgebung einspielen
Update-Paket hochladen, Update-Assistent starten, Datenbank-Migration durchführen. Danach Shop-Frontend, Kasse und Backend einmal durchklicken. Plugins einzeln aktivieren und auf Fehler prüfen. Mailqueue und Zahlungsarten testen.
Schritt 4: Fehler beheben oder Plugins austauschen
Liste aller gefundenen Fehler anlegen. Zu jedem Fehler: Ursache (Plugin-Version, Template-Patch, Server-Voraussetzung) + Gegenmaßnahme (Update, Austausch, Anpassung). Wir übernehmen diesen Schritt für individuelle Erweiterungen.
Schritt 5: Go-Live mit Maintenance-Fenster
Maintenance-Fenster ankündigen (1-2 Stunden reichen). Backup der Live-Datenbank, Update einspielen, Smoke-Test durch uns. Danach Shop wieder freigeben und 24 Stunden aktiv beobachten. Rollback-Plan liegt als Dokument vor.

