In welcher Reihenfolge Sie PrestaShop, PHP, Theme und Module aktualisieren, ohne den Shop zu beschädigen

Ein PrestaShop-Shop besteht aus vier Bausteinen, die unterschiedlich schnell altern: dem Core, der PHP-Version des Servers, dem Theme und den Modulen. Jeder hat seine eigenen Versionen, und jeder stellt Anforderungen an die anderen. Wenn Sie sie in beliebiger Reihenfolge aktualisieren, landen Sie früher oder später bei einer Kombination, die nicht funktioniert: ein Modul, das mit dem neuen PHP nicht startet, ein Theme, das eine Funktion aufruft, die der Core nicht mehr hat, oder ein Core, der sich nicht installieren lässt, weil PHP zu alt ist.

Die gute Nachricht: Die richtige Reihenfolge ergibt sich fast immer aus einer einzigen Regel. Hier ist sie, zusammen mit dem vollständigen Ablauf.

Die Regel: nie eine nicht unterstützte Kombination durchlaufen

Jede PrestaShop-Version unterstützt einen bestimmten Bereich von PHP-Versionen. Jedes Modul und jedes Theme gibt an (oder sollte angeben), mit welchen PrestaShop- und PHP-Versionen es funktioniert. Richtig aktualisieren bedeutet, so vorzugehen, dass nach jedem Schritt alle Bausteine innerhalb dessen bleiben, was sie unterstützen.

Daraus folgt in der Praxis: Sie können fast nie direkt ans Ziel springen. Läuft Ihr Shop auf einer alten Version mit altem PHP und verlangt die Zielversion ein neueres PHP, das die Ausgangsversion nicht unterstützt, brauchen Sie einen Zwischenschritt. Manchmal ist das eine Zwischenversion des Cores, manchmal eine PHP-Version, die beide unterstützen.

Bevor Sie etwas anfassen: Bestandsaufnahme

Erstellen Sie eine Tabelle mit allem, was im Shop steckt. Ohne sie ist die Reihenfolge reines Raten.

• Genaue Core-Version und die PHP-Version, die die Website nutzt (die nicht dieselbe sein muss wie im Terminal des Servers).
• Theme: Standard-Theme, gekauftes oder individuell entwickeltes Theme, ob es ein Child-Theme gibt und wer es pflegt.
• Installierte Module mit Version, Autor und Bezugsquelle. Markieren Sie die, die Sie nicht mehr nutzen: Diese werden nicht aktualisiert, sondern entfernt.
• Overrides im Ordner override/. Sie brechen als Erste, wenn sich der Core ändert, weil sie ganze Klassen oder Methoden ersetzen, deren Signatur sich geändert haben kann.
• Externe Anbindungen: ERP, Zahlungsanbieter, Marktplätze, Versanddienstleister. Jede davon ist ein Modul oder ein Skript, das ebenfalls von Versionen abhängt.

Notieren Sie für jedes Modul die neueste Version, die mit Ihrem aktuellen Core und mit dem Ziel-Core kompatibel ist. Die Module ohne Version für das Ziel sind die eigentliche Arbeit des Projekts: Sie brauchen einen Ersatz, müssen die Version beim Autor anfragen oder das Modul anpassen.

Die Reihenfolge, die in den meisten Fällen funktioniert

1. Vollständige Sicherung von Dateien und Datenbank, und prüfen Sie, dass sie sich wiederherstellen lässt.
2. Entfernen Sie Überflüssiges. Deinstallierte Module, die noch auf der Festplatte liegen, installierte Module, die niemand nutzt, verwaiste Overrides. Jeder Baustein, den Sie entfernen, muss nicht mehr aktualisiert und getestet werden.
3. Aktualisieren Sie die Module innerhalb Ihrer aktuellen Version bis zur neuesten Version, die diese unterstützt. Oft funktioniert genau diese Version bereits auch auf dem Ziel-Core, und so erfolgt der große Sprung mit aktuellen Modulen.
4. Aktualisieren Sie das Theme auf die neueste Version, die mit Ihrem aktuellen Core kompatibel ist, sofern der Hersteller eine anbietet. Bei einem individuellen Theme prüfen Sie vorher die Templates, die sich zwischen Versionen am stärksten ändern: Checkout, Warenkorb und Produktseite.
5. Aktualisieren Sie den Core, zuerst auf die letzte Revision Ihres Zweigs und danach, falls nötig, auf den nächsten Zweig.
6. Stellen Sie die PHP-Version um auf die neueste, die der neue Core unterstützt und die alle Ihre Module vertragen.
7. Prüfen Sie Module und Theme erneut: Manche haben eine eigene Version für den neuen Zweig, die sich erst installieren lässt, wenn der Core bereits aktualisiert ist.

Warum auf einer Kopie und nicht im Live-Shop

All das wird zuerst auf einer Kopie des Shops geprobt, mit denselben Dateien, derselben Datenbank und nach Möglichkeit demselben PHP und derselben Serverkonfiguration. Auf der Kopie dürfen Sie Fehler machen, zurückgehen und wiederholen. Im Live-Shop sehen Ihre Kunden jeden fehlgeschlagenen Versuch.

Halten Sie während der Probe jeden Schritt so genau fest, dass Sie ihn wiederholen können: welches Modul aktualisiert wurde, in welcher Reihenfolge, welche Einstellung von Hand geändert werden musste, welche Theme-Datei korrigiert wurde. Am Tag der Umstellung wird nicht improvisiert: Man arbeitet die Liste ab.

Was Sie nach jedem Schritt testen sollten

• Startseite, eine Kategorie mit Filtern, eine Produktseite mit Kombinationen und die Suche.
• Kundenregistrierung, Anmeldung und Passwort-Wiederherstellung.
• Eine vollständige Bestellung mit jeder Zahlungsart, im Testmodus des jeweiligen Anbieters, bis die Bestellung im richtigen Status erscheint.
• Die E-Mails an den Kunden (ohne dass sie tatsächlich jemanden erreichen: Auf der Kopie muss die Post abgefangen werden).
• Back-Office: Bestellliste, Detailansicht einer Bestellung, PDF-Rechnung, Bearbeitung eines Produkts.
• Das PHP-Fehlerprotokoll und das von PrestaShop: Auch was die Seite nicht zum Absturz bringt, zählt.

Was typischerweise kaputtgeht

• Overrides, die Core-Methoden neu definieren, die sich geändert haben. Das Symptom ist ein fataler Fehler direkt nach dem Update, manchmal nur auf einer bestimmten Seite.
• Zahlungsmodule in alten Versionen, die entfernte Hooks oder Klassen verwenden. Sie sind am heikelsten, weil der Fehler in der Rückleitung vom Zahlungsanbieter liegen kann: Der Kunde bezahlt, und die Bestellung wird nicht angelegt.
• Theme-Templates, die Variablen erwarten, die der Core nicht mehr übergibt oder die anders heißen.
• Entfernte PHP-Funktionen oder Verhaltensweisen, die mit der neuen Version von einer Warnung zu einem Fehler werden. Ein Modul, das mit unterdrückten Warnungen lief, kann ganz aufhören zu funktionieren.
• Caches, die kompilierte Klassen der vorherigen Version behalten. Sie zu leeren gehört zum Ablauf und ist kein Trick in letzter Minute.

Das Zeitfenster der Umstellung

Wenn die Probe abgeschlossen ist, wählen Sie den Zeitpunkt für den Live-Shop:

• Eine Zeit mit wenig Traffic, die Sie in Ihrer Statistik nachsehen können, nicht die, die alle vermuten.
• Fern von Kampagnen und Tagen mit vielen Versendungen. Aktualisieren Sie nicht am Vorabend des Schlussverkaufs und nicht an einem Freitagnachmittag, wenn am Montag niemand nachsehen kann.
• Mit den Leuten in Reichweite: wer die Umstellung durchführt, wer die Zahlungen testet und wer bei Bedarf den Hoster anrufen kann.
• Mit einem schriftlichen Rückfallplan: welche Sicherung wiederhergestellt wird, wie lange das dauert und ab welchem Symptom die Rückkehr beschlossen wird. Sind zwischen Sicherung und Rückkehr Bestellungen eingegangen, müssen Sie wissen, wie Sie sie zurückholen.

Schalten Sie den Shop während der Umstellung in den Wartungsmodus, lassen Sie Ihre IP zum Testen zu und öffnen Sie ihn erst wieder, wenn Sie dieselbe Testliste wie bei der Probe abgearbeitet haben.

Nach der Umstellung

Die ersten Tage dienen der Beobachtung. Prüfen Sie das Fehlerprotokoll, gleichen Sie die Bestellungen mit den Zahlungseingängen beim Anbieter ab und fragen Sie den Kundenservice, ob ungewöhnliche Anfragen eingehen. Viele Fehler eines Updates zeigen sich nicht in der ersten Stunde, sondern erst, wenn jemand zum ersten Mal eine selten genutzte Funktion verwendet: einen bestimmten Gutschein, einen Versanddienstleister, der nur für bestimmte Provinzen angezeigt wird, oder eine Rechnungskorrektur.

Und halten Sie den Endstand in der Bestandsaufnahme fest. Das nächste Update beginnt dort, und es wird viel kürzer, wenn Sie nicht Jahre zwischen zwei Updates verstreichen lassen.

So lösen Sie es in PrestaShop

Bei Rekire erledigen wir diese Arbeit täglich, vom Revisions-Update innerhalb desselben Zweigs bis zur Migration zwischen Hauptversionen. Mit einem Support-Stundenpaket (20 oder 50 Stunden, je nach Größe des Shops) erstellen wir die Bestandsaufnahme von Core, PHP, Theme und Modulen, richten die Testkopie ein, proben die Update-Reihenfolge mit ihrer Testliste und spielen die Umstellung im Live-Shop in dem Zeitfenster ein, das Sie wählen. Die Stunden werden nach tatsächlichem Aufwand verbraucht, Sie können also mit der Bestandsaufnahme beginnen und danach entscheiden, wie weit Sie gehen.