Zum Inhalt

JTL-Shop-Update ohne Ausfall einspielen

Ein JTL-Shop-Update gehört zuerst auf eine Kopie. Backup, Plugins, Template und danach die Prüfung von Checkout, Zahlung, Mailversand und Widerruf.

StoreSchmide-Fuchs mit JTL-Kachel, Pfeil, Zahnrad und Paket — JTL-Shop-Update
Markus
Von Markus
Geschäftsführer, StoreSchmide
Veröffentlicht am · 3 Min. LesezeitJTL-Shop
Inhaltsverzeichnis

Ein JTL-Shop-Update ist kein Redesign. Es ist ein Eingriff in das System, das gerade Bestellungen annimmt. Die Version, die im Backend steht, ist selten das Risiko. Das Risiko ist, sie auf der Instanz einzuspielen, auf der der Umsatz läuft, ohne zu wissen, welches Plugin oder welche Template-Änderung danach nicht mehr mitspielt.

Patch, kleinere Version, großer Sprung

Nicht jedes Update ist gleich tief.

  • Ein Patch schließt eine Lücke oder einen Fehler im selben Versionszweig. Der Shop soll sich danach anfühlen wie vorher, nur sicherer.
  • Eine kleinere Version bringt Funktionen mit, zum Beispiel eine gesetzliche Pflicht wie den Widerrufsbutton. Hier können Templates und Plugins eine Anpassung brauchen.
  • Ein großer Sprung über mehrere Zweige hinweg ist ein Projekt: Datenbank, Template und der Plugin-Stand müssen mitziehen. Den plant ihr, den schiebt ihr nicht an einem Dienstagmittag dazwischen.

Welche Version ihr fahrt, steht im Backend im Informations-Widget des Dashboards. Daran hängt, welcher Patch überhaupt der richtige ist. Beim SSTI-Fall in JTL-Shop 5 war das der Unterschied zwischen 5.7.2, 5.6.2, 5.5.4 und einem Back-Patch für ältere Zweige. Details dazu stehen im Beitrag zur Sicherheitslücke im JTL-Shop.

Was vorher stehen muss

Drei Dinge, bevor die neue Version irgendwo landet:

  • Backup von Dateien und Datenbank. Ein Update, das die Datenbank migriert, lässt sich nicht mit einem Klick zurückdrehen. Ohne Backup gibt es keinen Plan B.
  • Plugin-Stand. Jedes aktive Plugin gegen die Zielversion halten. Ein inkompatibles Plugin nimmt man vor dem Update raus oder aktualisiert es mit, nicht erst wenn der Checkout schon steht.
  • Eigene Template-Anpassungen. Wer am NOVA-Template oder einem Child-Template gebaut hat, vergleicht die geänderten Dateien mit der neuen Version. Sonst überschreibt das Update eine Anpassung, oder die alte Datei überschreibt den Patch.

Die Kopie des Shops, auf der ihr das probiert, muss nah am Live-Stand sein: dieselbe Shop-Version als Ausgang, dieselben Plugins, dasselbe Template. Eine leere Testinstallation sagt nichts darüber, ob euer Checkout danach noch abrechnet.

Die Reihenfolge

  1. Live-Stand sichern, Dateien und Datenbank.
  2. Diesen Stand auf die Testumgebung bringen.
  3. Dort aktualisieren, Plugins nachziehen, Template-Abweichungen sich ansehen.
  4. Den Testauftrag durchspielen, siehe unten.
  5. Erst dann dasselbe Update, in derselben Reihenfolge, auf dem Live-Shop. Am besten in einem Fenster, in dem wenig bestellt wird, und mit jemandem, der den Checkout danach sofort prüft.

Zwischen Test und Live nichts mehr am Template ändern. Sonst spielt ihr einen anderen Stand ein als den, den ihr geprüft habt.

Was ihr danach prüft

Die Startseite ist der schlechteste Test. Sie lädt oft auch dann, wenn der Kaufweg kaputt ist. Durchspielen:

  • Artikel, Warenkorb, Checkout. Eine Bestellung mit der Zahlart, die ihr wirklich nutzt, nicht mit einem Test-Schalter, den kein Kunde sieht.
  • Mailversand. Bestellbestätigung und Versandmail. Genau dort saß die SSTI-Lücke, und genau dort fällt ein Template-Fehler zuerst auf.
  • Rechtliche Funktionen. Widerrufsbutton, Widerrufsbelehrung, Pflichtseiten. Seit Juni 2026 gehört der Button zum Shop, siehe Widerrufsbutton im Onlineshop. Ein Update darf ihn nicht aus dem Template werfen.
  • Suche und Bestand. Ein bekannter Artikel muss treffbar bleiben, der Bestand nach der Testbestellung plausibel sein.
  • Backend. Die Dashboard-Version muss die Zielversion zeigen. Ein Hinweis auf eine veränderte Datei ist nach einem manuellen Patch manchmal gewollt, nach einem regulären Update ein Zeichen, dass eine alte Datei liegen geblieben ist.

Stimmt einer dieser Punkte nicht, bleibt der Live-Shop auf der alten Version, bis die Kopie es tut. Der Umsatz eines Nachmittags ist teurer als ein Tag Wartezeit.

Fazit

Ein JTL-Shop-Update ist beherrschbar, wenn die Kopie zuerst dran ist und danach der Kaufweg geprüft wird, nicht die Startseite. Sicherheitsupdates setzt ihr trotzdem zeitnah um. Warten, bis das nächste Theme-Projekt ansteht, lässt bekannte Lücken offen.

Wenn ihr das nicht selbst zwischen Lager und Tagesgeschäft schieben wollt, übernehmen wir Update, Test und das Einspielen. Das ist die JTL-Shop-Betreuung.

Häufige Fragen

Kann ich ein JTL-Shop-Update direkt auf dem Live-Shop einspielen?

Besser nicht. Zuerst auf einer Kopie, die denselben Plugin- und Template-Stand hat. Erst wenn Checkout, Zahlung und Mailversand dort durchlaufen, kommt dasselbe Update auf den Live-Shop.

Was muss ich nach dem Update prüfen?

Einen echten Kaufweg: Artikel, Warenkorb, Checkout, Zahlart, Bestellmail und Versandmail. Dazu Widerrufsbutton, Suche und die Versionsanzeige im Backend. Die Startseite allein sagt wenig.

Wie dringend ist ein Sicherheitsupdate?

Zeitnah. Ein bekanntes Loch wartet nicht auf das nächste Theme-Projekt. Der Weg bleibt derselbe: Kopie, Update, Prüfung, dann live. Der SSTI-Patch in JTL-Shop 5 ist so ein Fall.

Das könnte dich auch interessieren