Ein wiederholbar erzeugter Klon Ihres Live-Shops — mit Ihren Artikeln, Ihrer Konfiguration, Ihren Plugins und Ihrem angepassten Template. Dort spielen Sie das Update ein, vergleichen den Zustand vorher und nachher und entscheiden erst danach.
Nach einem Shop-Update wurden alle wichtigen Seiten aufgerufen. Jede antwortete mit dem Status 200 — technisch also einwandfrei. Das Update galt als geglückt.
Tatsächlich waren sieben von acht Template-Blöcken still ausgefallen. Die Seiten luden, das Gerüst stand, nur der Inhalt fehlte an Stellen, die man nicht sofort ansieht. Bemerkt wurde es später — über Umsatz, nicht über Technik.
Daraus folgt: Ein Erreichbarkeitstest beweist gar nichts. Man muss den Zustand vorher und nachher tatsächlich aufnehmen und vergleichen. Genau das macht dieses Werkzeug.
Was ist überhaupt da? Shop-Version, Plugins, Template-Anpassungen, Datenmenge, Serverumgebung — der Ausgangszustand wird schriftlich festgehalten.
Eigenes Verzeichnis, eigene Datenbank. Beides ist Pflicht: JTL-Shop 5 kennt keine Tabellenpräfixe, zwei Shops in einer Datenbank sind nicht vorgesehen.
Der Prüfstand darf nichts nach draußen tun. Keine Bestellbestätigungen, keine Zahlungsdienste, keine Schnittstellen zur Warenwirtschaft — sonst richtet der Test den Schaden an, den er verhindern soll.
Der Ist-Zustand wird gemessen: welche Seiten was ausliefern, welche Template-Blöcke greifen, welche Plugins sich melden. Das ist der Vergleichsmaßstab.
Über das Backend der Box, nicht über einen Skriptaufruf. Sonst prüft man einen anderen Weg als den, den Sie später tatsächlich gehen.
Dieselbe Messung noch einmal — und dann die Gegenüberstellung. Was ist verschwunden, was hat sich verändert, was meldet plötzlich anders?
↔ seitlich wischen, um das ganze Bild zu sehen
Testshop aus dem Live-Shop erzeugen, das Update dort einspielen, den Zustand vergleichen.
Lesen →Ein Update kann fehlerfrei durchlaufen und trotzdem Inhalte zerstören.
Lesen →update/migrations ist seit Shop 5.4 leer. Die ausgeführten stehen woanders.
Template-Blöcken fielen bei einem echten Update still aus — bei durchgehend fehlerfreien Statusmeldungen. Der Vergleich vorher/nachher fand es, der Erreichbarkeitstest nicht.
Tabellen fasst der Sprung 5.5.4 auf 5.6.2 an. Erst diese Messung macht einen zielgenauen Rückweg möglich, statt im Schadensfall alles zurückspielen zu müssen.
Prüfungen im Selbsttest des Werkzeugs — es misst also auch sich selbst, bevor es Ihren Shop misst.
Ein Nebenbefund, der viel Sucherei erspart hat: Die tatsächlich ausgeführten Migrationen von JTL-Shop 5 liegen nicht dort, wo man sie vermutet. Das naheliegende Verzeichnis ist seit Version 5.4 leer — was dort steht, sagt über ein Update nichts aus.
Nein — und das ist keine Vorsichtsmaßnahme, sondern zwingend. JTL-Shop 5 arbeitet ohne Tabellenpräfixe, zwei Shops passen nicht in eine Datenbank. Vor allem aber führt ein Update Änderungen an der Tabellenstruktur aus. Auf der Live-Datenbank wäre das genau der Schaden, den das ganze Vorhaben verhindern soll.
Produktive Lizenzen werden vom Shop nicht automatisch deaktiviert; im Backend erscheint lediglich ein Hinweis. Nur Testlizenzen laufen ab und schalten sich dann ab. Für den Prüfstand ist eine abweichende Adresse damit unkritisch.
Vor jedem Update, das Sie ernst nehmen. Der Wert liegt gerade in der Wiederholbarkeit: Der Klon ist kein einmalig von Hand gebautes Gebilde, sondern etwas, das sich jederzeit neu erzeugen lässt — sonst prüft man irgendwann einen veralteten Stand.
Er kann bestehen bleiben oder weggeräumt werden. Wichtig ist nur, dass er von Suchmaschinen abgeschirmt ist und keine Verbindungen nach außen aufbaut — beides gehört zum Abklemmen im dritten Schritt.
Vorher ist es ein Test. Nachher ist es Schadensbegrenzung.
Individuelle Software und Werkzeuge für Betriebe, die mit Standardlösungen an Grenzen stoßen.