Verwaltung von Datenbankänderungen bei Modulaktualisierungen in PrestaShop

Es gibt eine bestimmte Supportanfrage, die mir mittlerweile richtig Angst macht. Ein Händler aktualisiert ein Modul; die Aktualisierung scheint zunächst erfolgreich zu verlaufen, doch dann funktioniert irgendetwas nicht mehr. Nie der gesamte Shop. Eine einzelne Seite des PrestaShop-Controllers verhält sich fehlerhaft, ein Konfigurationswert lässt sich nicht speichern oder eine Spalte in einer Produktliste ist plötzlich leer. Bei genauerer Betrachtung ist der Modulcode auf dem neuesten Stand, die zugrundeliegende Datenbank jedoch noch auf der alten Version.

Genau diese Lücke ist Gegenstand dieses Artikels. Ein PrestaShop-Modul besteht nicht nur aus dem ausgelieferten PHP-Code, sondern aus diesem PHP-Code plus den Tabellen und Spalten, die dieser erwartet. Fehlt das PrestaShop-Datenbank-Update, das normalerweise mit einer Code-Veröffentlichung ausgeliefert wird, erhält man ein Modul, das zwar installiert ist und scheinbar funktioniert, aber dennoch einen Fehler enthält.

Das ist mir selbst schon mehr als einmal passiert. Im Folgenden beschreibe ich, was ich dabei gelernt habe. Aktualisierungen der PrestaShop-Moduldatenbank, auf die harte Tour.

1.0 Wie PrestaShop-Modulaktualisierungen die Datenbank tatsächlich verarbeiten

[Caption id = “attachment_840862” align = “Aligncenter” width = “1237”] Beim Update-Sprung von Version 1.9.0 auf 2.1.0 werden keine Aktualisierungen übersprungen, sondern alle dazwischenliegenden Aktualisierungsskripte der Reihe nach ausgeführt.

Hier kursieren viele Annahmen, und einige davon sind falsch.

Füge eine neue Version hinzu in /modules/ Ihre Installationsroutine wird nicht erneut ausgeführt. Tabellen bleiben unberührt. Stattdessen passiert Folgendes: PrestaShop liest die Modul-Konfiguration. Aktualisierung / Ordner, findet die Dateien mit dem Namen Upgrade .php Es befindet sich zwischen der aufgezeichneten Version und der Version, die Ihre Modulklasse deklariert, und führt diese der Reihe nach aus.

Ein Shop auf Version 1.9.0, der Version 2.1.0 empfängt, führt drei Skripte nacheinander aus.

Daraus ergeben sich drei Dinge, und alle drei sind wichtig für Änderungen an der PrestaShop-Datenbank.

Die Version in der `module`-Tabelle ist die maßgebliche Quelle. Nicht die in Ihrer Hauptklassendatei. PrestaShop liest beide. Ausschlaggebend ist die gespeicherte Datei, die bestimmt, wie viele Aktualisierungsskripte ausgeführt werden.

Ihre `install()`-Methode ist nur für Neuinstallationen gedacht. Angenommen, Version 2.0 benötigt eine neue Tabelle. Fügen Sie sie ein. installieren() Wer auf Version 2.0 umsteigt, ist abgesichert. Der Nutzer von Version 1.9 erhält nichts, da die Installation vor einem Jahr abgeschlossen wurde und nicht mehr aktualisiert wird.

Ein einziger Fehler legt alles lahm. Return falsch Wenn eine Upgrade-Funktion ausgeführt wird, passieren drei Dinge: PrestaShop hält an, speichert die betroffene Version und deaktiviert das Modul. Der nächste Skriptvorgang wird nicht ausgeführt. Dies ist beabsichtigt, bedeutet aber, dass eine unvollständig angewendete Schemaänderung zwar die Funktionalität einschränkt, aber nicht vollständig zum Absturz führt.

Das Automatische Aktualisierung für Module aktivieren Auf dieser Seite sind die Regeln für die Dateibenennung festgelegt. Lesen Sie sie sich einmal gründlich durch, anstatt sie aus dem Gedächtnis abzurufen.

Die Namensfalle der Upgrade-Funktion

Das hat mich einen Nachmittag gekostet. Upgrade-Modul 201 or upgradeModule201 Es dient als Funktionsname, und PrestaShop sucht nach beiden. Bevor Ihre Datei eingebunden wird, prüft PrestaShop außerdem, ob einer dieser Namen bereits existiert. Wird er gefunden, wird die Datei als Duplikat markiert und übersprungen.

Das Kopieren eines alten Upgrade-Skripts als Vorlage ist genau der Grund, warum viele in diese Situation geraten. Der Name im Skript wird nie geändert. Es findet kein Upgrade statt, und die Fehlermeldung ist wenig aussagekräftig.

2.0 PrestaShop-Datenbankmigration: Was läuft in realen Shops schief?

Das alles passierte in Läden, in denen ich gearbeitet habe.

PrestaShop-Datenbankschemaänderungen, die zwischen verschiedenen Installationen abweichen

Version 2.0 benötigt eine neue Spalte, daher aktualisieren Sie bitte. installieren() und ein Upgrade-Skript schreiben. Beides korrekt. Drei Versionen später benennt jemand den Modulordner um oder ein Händler installiert das Modul neu. Bei manchen Installationen erstellte `install()` diese Spalte, bei anderen der Upgrade-Pfad. Zwei Definitionen, die sich auseinanderentwickeln, und eine einzige Versionsnummer deckt nun beide ab.

Die Definition befindet sich also in einer einzigen Methode, die von beiden Pfaden aufgerufen wird. Änderungen am PrestaShop-Datenbankschema können nicht voneinander abweichen, wenn es nur eine einzige Definition gibt.

Upgrade-Skripte, die einen sauberen Ausgangspunkt voraussetzen

ALTER TABLE … ADD COLUMN Wenn eine Spalte bereits existiert, wird ein Fehler ausgelöst, Ihre Funktion gibt „false“ zurück, und das Modul wird deaktiviert. Unterbrechen Sie eine vorherige Aktualisierung, stellen Sie eine Teilsicherung wieder her oder synchronisieren Sie zweimal vom Staging-Bereich: Eine dieser Möglichkeiten führt zum selben Ergebnis.

Jede Schemaänderung, die ich jetzt vornehme, prüft zuerst etwas. Das Hinzufügen einer Spalte bedeutet … SPALTEN ANZEIGEN Das vorherige Erstellen einer Tabelle bedeutet TISCHE ANZEIGEN, ein Index bedeutet INHALTSVERZEICHNIS ANZEIGENEin paar Zeilen, und das Skript übersteht einen zweiten Durchlauf. Das ist wichtig, denn die Datenbank eines Fremden kann sich in jedem beliebigen Zustand befinden. WENN NICHT EXISTIERT in beiden MySQL und MariaDBAllerdings nur bei einigen Operationen, daher ist die explizite Prüfung besser geeignet.

Multistore: Konfigurationszeilen, die nur für einen Shop geschrieben wurden

Diese Version ist still und heimtückisch. Es gibt jetzt eine Shop-spezifische Einstellung. Die Standardzeile wurde vom Upgrade-Skript erstellt und vom Entwickler getestet – alles scheint in Ordnung. Allerdings wurde nur eine Zeile für den jeweiligen Shop geschrieben, und der Händler betreibt vier Shops.

Drei Shops weisen diese Angabe nun nicht mehr auf. Je nachdem, wie Ihr Code dies interpretiert, erhalten Sie entweder eine PHP-Warnung, einen leeren Wert, der als gültige Einstellung behandelt wird, oder eine leere Stelle, an der eigentlich ein Preis stehen sollte. Dokumentation für mehrere Filialen Umfasst die Kontextregeln. Durchläuft jede Shop-ID bei jedem Upgrade, das die Konfiguration oder die Daten pro Shop betrifft.

Bei einer Installation in einem einzelnen Shop ist dieser Fehler nicht sichtbar.

ALTER TABLE-Sperren auf großen Katalogtabellen

Das Hinzufügen einer Spalte zu einer Tabelle mit 400,000 Zeilen erfolgt nicht sofort. Je nach Vorgang, MySQL-Version und Speichermodul kann es erforderlich sein, die gesamte Tabelle zu kopieren. Im laufenden Betrieb während der Öffnungszeiten dauert diese Sperre lange genug, damit Kunden sie bemerken.

Deshalb prüfe ich die Tabellengröße, bevor ich die Migration schreibe. Ist sie groß, nutze ich ein Wartungsfenster oder strukturiere die Tabelle um, um einen erneuten Aufbau zu vermeiden.

Der Konfigurationsschlüssel ohne Standardwert

Die Variante, die ich am häufigsten in den Modulen anderer Leute sehe, und dabei wird keine Tabelle verwendet.

Sie fügen eine Einstellung in der neuen Version hinzu. Das Admin-Formular liest diese. Ebenso der Front-Controller. Beide wurden auf einem Rechner entwickelt, auf dem die Einstellungsseite bereits mindestens einmal gespeichert wurde. Der Schlüssel ist also vorhanden und alles scheint korrekt zu sein. Veröffentlichen Sie das, und jede bestehende Installation liest die Einstellung. Konfiguration Schlüssel, den nie jemand geschrieben hat.

Was zurückkommt, ist falschIhr Standardwert taucht nie auf, auch keine leere Zeichenkette, die Sie zumindest prüfen könnten. Stattdessen wird sie als Zahl verwendet oder an eine Funktion übergeben, die eine Zeichenkette erwartet. Ist der Debug-Modus deaktiviert, kommt man oft ungeschoren davon: Der Händler sieht eine leicht fehlerhafte Seite und denkt sich nichts dabei. Ist der Debug-Modus aktiviert, wird der Fehler als Warnmeldung oder Typfehler angezeigt. So kommt es, dass Sie die Meldung „Das Modul funktioniert im Debug-Modus nicht“ erhalten, obwohl nur der Debug-Modus selbst korrekt arbeitet.

Derselbe Code, einmal mit und einmal ohne Angabe des Standardwerts.

Die Lösung ist umständlich. Jeder neue Konfigurationsschlüssel erhält seinen Standardwert im Upgrade-Skript für jeden Shop, inklusive des Codes zum Auslesen. Lesen Sie das Skript daher unbedingt mit Vorsicht, da Sie nicht sicher sein können, dass das Upgrade erfolgreich war.

PrestaShop-Moduldatenbankmigration versus Schemaänderung

Schemaänderungen sind der einfache Teil. Der schwierige Teil besteht darin, die Bedeutung vorhandener Daten zu ändern: eine Spalte in zwei Teile aufzuteilen, ein CSV-Feld in eine verknüpfte Tabelle zu verschieben, einen Status neu zu kodieren.

Dort habe ich den größten Schaden gesehen. Ein verpfuschter ALTER TABELLE Ein Fehler schlägt lautstark fehl; eine misslungene Datentransformation gelingt zwar, erzeugt aber unverständliche Daten. Bei einer Datenbankmigration eines PrestaShop-Moduls, die Daten verschiebt, muss die Anzahl der Daten vor und nach der Migration ermittelt und anschließend verglichen werden. Dies sollte besser im Upgrade-Skript selbst entdeckt werden als von einem Händler drei Wochen später.

Best Practices für das PrestaShop-Modul-Upgrade 3.0, die ich tatsächlich verteidigen würde

Diejenigen, die mich gerettet haben:

Jede Migration sollte idempotent sein

Beim zweiten Durchlauf sollte sich nichts ändern, was beim ersten Durchlauf nicht bereits berücksichtigt wurde. Sobald diese Eigenschaft verfügbar ist, verschwindet eine ganze Kategorie von Supportproblemen, da der Zustand der Datenbank nicht mehr zuerst ermittelt werden muss. Bevor Sie rohes SQL auf die Kerntabellen von PrestaShop anwenden, sollten Sie Folgendes beachten: Datenbankebenen-Notizen sind eine Stunde wert.

Die geschützte Version übersteht einen zweiten Durchlauf.

Protokolliere jeden Fehler, anstatt stillschweigend „false“ zurückzugeben.

Ein nackter return false Das reicht PrestaShop, um das Modul zu stoppen und zu deaktivieren. Für Sie reicht es nicht. Daher sollten Sie den Vorgang protokollieren. Fangen Sie alle Ausgaben ab und übergeben Sie diese zusammen mit Modulname und -version an PrestaShopLogger. Andernfalls meldet ein Händler ein fehlgeschlagenes Update, und Sie tappen im Dunkeln.

Bei PHP 7 und höher, catch Fehler und auch die ExceptionWenn in Ihrem eigenen Migrationscode ein Typfehler auftritt, wird dieser als ein FehlerEin Handler überwacht also nur Folgendes: Exception lässt es durch.

Unterstützen Sie jede Version, die Sie jemals ausgeliefert haben.

Ein Händler kann jede beliebige Version verwenden, die Sie veröffentlicht haben. Jemand, der von Version 1.4 auf 3.0 aktualisiert, führt alle dazwischenliegenden Skripte der Reihe nach aus, sodass jedes Skript mit dem Schema des vorherigen Skripts arbeiten muss. Deshalb verbleiben alte Upgrade-Dateien im Modul. Jemand, der zwei Jahre zurückliegt, hat keine andere Möglichkeit, fortzufahren.

Testen Sie auf der Staging-Umgebung, nicht auf einer sauberen lokalen Installation.

Eine Neuinstallation der neuen Version sagt nichts über das Upgrade aus. Stattdessen sollten Sie die alte Version installieren, realistische Daten eingeben und dann das Upgrade durchführen. Dies gilt auch für Multistore-Systeme, sofern diese unterstützt werden.

Noch besser: Nehmen Sie eine Kopie eines echten Shops und führen Sie das Upgrade darüber durch. Ihre lokale Installation verfügt über saubere Daten und vier Produkte, weshalb keine Ergebnisse angezeigt werden. Ein echter Shop hingegen enthält unvollständige Importe, Zeilen, die von einem vor zwei Jahren deinstallierten Modul übrig geblieben sind, Spalten, die ein vorheriger Entwickler manuell hinzugefügt hat, und einen so großen Katalog, dass… ALTER TABELLE dauert eine Weile.

Und dann kommt es auf den Zeitpunkt an. Ein Upgrade, das laut realen Daten sechs Minuten dauern soll, lässt sich besser bei der Buchung eines Wartungsfensters herausfinden als freitags um elf Uhr.

Erstellen Sie vor Schemaänderungen ein Backup und geben Sie dies an.

Vor einem Modul-Upgrade wird kein Snapshot Ihrer Tabellen erstellt. Weder von PrestaShop noch von irgendeinem anderen System. Wenn der Händler also kein Backup hat und die Migration mitten in der Datentransformation abbricht, sind diese Daten verloren. Weisen Sie im Changelog darauf hin, anstatt dies gemeinsam festzustellen.

Wiederherstellung eines fehlgeschlagenen PrestaShop-Datenbankupdates

Ein Update im Live-Shop ist fehlgeschlagen; das Modul wurde deaktiviert. Ungefähr in dieser Reihenfolge:

Ermitteln Sie, welche Version fehlgeschlagen ist. Das wird protokolliert, und falls Sie eine Log-Nachricht verfasst haben, wird diese ebenfalls dort gespeichert. Dadurch wissen Sie, welches Skript Sie öffnen müssen und welche Änderungen vor dem Abbruch vorgenommen wurden.

Prüfen Sie das tatsächliche Schema, nicht die Versionsnummer. Um so Modulen Die Tabelle gibt an, was das letzte erfolgreiche Upgrade geschrieben hat. Die eigentlichen Tabellen liefern die Antwort; sie werden mit dem verglichen, was das fehlgeschlagene Skript versucht hat.

Nach vorne blicken, nicht nach hinten. Das Zurücksetzen der Versionsnummer ist zwar verlockend, aber meist falsch, da die älteren Skripte bereits ausgeführt wurden und deren erneute Ausführung mit einem teilweise geänderten Schema ein Problem in ein dreifaches verwandelt. Schreiben Sie eine Korrekturmigration vom aktuellen Schema zum Soll-Schema.

Anschließend muss herausgefunden werden, warum die Migration nicht idempotent war. Das ist der eigentliche Fehler.

Eine kurze Checkliste vor dem Versand eines Modul-Updates

Die Liste, die ich führe:

1. Hauptklassenversion, höchste upgrade-*.php Datei: Stimmen die Dateien überein?
2. Jede Upgrade-Funktion ist nach der Version ihrer jeweiligen Datei benannt?
3. Bei jeder Schemaänderung zuerst prüfen, ob sie bereits angewendet wurde?
4. Jede Konfigurationsschleife durchläuft alle Shops?
5. Jedem neuen Konfigurationsschlüssel wird ein Standardwert für bestehende Installationen zugewiesen?
6. Haben Sie schon einmal gegen eine Simulation eines echten Ladens gespielt?
7. Alte Version installiert, Daten hinzugefügt und dann aktualisiert?
8. Gleicher Pfad bei Multistore?
9. Etwas Nützliches wurde vor jedem Protokolleintrag hinzugefügt. return false?
10. Fang Fehler und auch die Exception?
11. Sind für Händler, die mehrere Versionen zurückliegen, noch alte Upgrade-Dateien vorhanden?
12. Änderungsprotokoll mit der Aufforderung an Händler, Daten zu sichern?
13. Auf einem großen Tisch, wie lang ist das? ALTER Ein Schloss in der Hand?

Die Punkte 6 und 7 werden oft übersprungen, aber zusammen erfassen sie den größten Teil davon.

Fazit

PrestaShop-Modul-Upgrade Probleme sind aus einem Grund unangenehm: Sie werden nirgends angekündigt. Das Modul meldet seine neue Version problemlos. Die Admin-Seite lädt. Keine Protokolle, es sei denn, man hat sie selbst geschrieben. Währenddessen erwartet der Code das eine, die Datenbank das andere, und das bleibt unberührt, bis jemand die eine Funktion nutzt, die dazwischen liegt.

Behandeln Sie das Schema als Teil des Releases. Schreiben Sie Migrationen, die auch nach einem zweiten Durchlauf bestehen. Protokollieren Sie alle Vorgänge. Testen Sie die Migration in der Staging-Umgebung, bevor sie von Händlern verwendet wird. Auf Framework-Seite: PrestaShop Modulentwicklungsdokumentation ist der Anfang.

Wenn Sie Fragen zur Performance oder Migration Ihrer Website haben oder Unterstützung benötigen, helfen Ihnen unsere Experten gerne weiter. Kontaktieren Sie das Knowband-Team unter [E-Mail geschützt] Heute noch auf der Suche nach zuverlässigen E-Commerce-Plugins, die auf Ihre E-Commerce-Anforderungen zugeschnitten sind.