Ein Update auf eine neue Hauptversion entscheidet sich selten am PrestaShop-Kern, der sich in den meisten Fällen sauber aktualisiert. Es entscheidet sich an Ihren Modulen. In einem Shop mit vierzig Modulen genügt ein einziges, das in den Bestellprozess eingreift und nicht mehr kompatibel ist, um die gesamte Migration zu blockieren.
Das Modul-Audit gehört deshalb an den Anfang, noch vor das Angebot.
Was sich tatsächlich ändert
PrestaShop 9 setzt auf neuere Versionen von PHP und Symfony, woraus drei Familien von Brüchen entstehen.
Brüche durch PHP. Strengere Typisierung, veraltete dynamische Eigenschaften, entfernte Funktionen. Ein Modul, das vor fünf Jahren geschrieben und nie überarbeitet wurde, erzeugt fatale Fehler, keine Warnungen.
Brüche durch das Framework. Module, die Symfony-Controller erweitern oder Services deklarieren, müssen der neuen Version folgen. Das trifft die jüngeren, gut gebauten Module, die damit paradoxerweise stärker exponiert sind als rein legacy gebaute.
Brüche durch PrestaShop selbst. Aus den historischen Klassen entfernte Methoden, gestrichene oder umbenannte Hooks, Änderungen an den Templates des Standardthemes.
Die Inventur als erstes Ergebnis
Erstellen Sie vor jedem Eingriff eine Tabelle mit einer Zeile pro Modul und sechs Spalten.
- Technischer Name und installierte Version.
- Anbieter und ob es ihn noch gibt. Ein verschwundener Anbieter bedeutet ein Modul ohne Zukunft.
- Datum der letzten verfügbaren Aktualisierung. Ab achtzehn Monaten ohne Veröffentlichung gilt das Modul als aufgegeben, bis das Gegenteil bewiesen ist.
- Angegebene Kompatibilität mit der Zielversion, wobei zu trennen ist, was auf der Produktseite steht und was tatsächlich getestet wurde.
- Kritikalität: greift das Modul in Zahlung, Bestellprozess oder Katalog ein, oder nur in eine nachrangige Anzeige?
- Vorhandene Overrides, sichtbar im Override-Verzeichnis. Das ist der aussagekräftigste Hinweis auf Fragilität.
Diese Tabelle ist in einem halben Tag gefüllt und bestimmt den gesamten weiteren Projektverlauf.
Die vier Kategorien
Jedes Modul fällt in eine davon, und die Behandlung unterscheidet sich.
Kompatibel und gepflegt. Sie aktualisieren und testen. Der einfachste Fall, und selten die Mehrheit.
Kompatibilität angegeben, aber nicht geprüft. Ein Satz auf einer Produktseite ist keine Abnahme. Diese Module gehören zuerst auf den Prüfstand, denn eine spät entdeckte Inkompatibilität kostet eine Verschiebung.
Aufgegeben. Zwei Auswege: einen Ersatz finden oder den Code übernehmen lassen. Die Übernahme lohnt nur, wenn die Funktion für Ihr Geschäft spezifisch ist.
Durch Bordmittel ersetzbar. Diese Kategorie wird regelmäßig unterschätzt. Jede Hauptversion übernimmt Funktionen, die zuvor ein Modul erforderten. Eine Migration ist der richtige Moment, um zu deinstallieren, was seinen Platz nicht mehr verdient.
In echten Audits streicht dieser letzte Durchgang oft fünf bis zehn Module von der Liste und entlastet das Projekt entsprechend.
Broken-Link-Checker PrestaShop 8 & 9 — Defekte Links & Fehlende BilderFinden Sie defekte Links und kaputte Bilder vor Ihren Kunden59,00€
Die häufigsten technischen Fallen
Für Entwickler und Agenturen kehren vier Brüche bei den zu überarbeitenden Modulen ständig wieder.
Die direkt auf den Controllern verfügbare Übersetzungsmethode ist verschwunden: Der Weg führt jetzt über die Modulinstanz. Overrides von Methoden mit geänderter Signatur erzeugen Kompatibilitätsfehler, insbesondere bei den Rendering-Methoden für asynchrone Antworten. Asynchrone Aufrufe der historischen Admin-Controller haben ihre Form geändert und verlangen, dass die Parameter anders übergeben werden. Und Module, die direkt in Kerntabellen geschrieben haben, stoßen auf Schemaänderungen.
Keine dieser Korrekturen ist für sich genommen komplex. Die Kosten entstehen durch die Menge.
Die Testumgebung
Nicht verhandelbar, und trotzdem regelmäßig übersprungen.
Sie muss auf einer aktuellen Kopie der Produktionsdatenbank beruhen, nicht auf einem Demodatensatz. Die meisten Inkompatibilitäten zeigen sich an echten Daten: Produkte mit hundert Kombinationen, Kunden mit unvollständigen Adressen, Bestellungen in vergessenen Status.
Zwei Vorsichtsmaßnahmen: Anonymisieren Sie die Kundendaten vor dem Kopieren, und deaktivieren Sie jeden Mailversand aus dieser Umgebung. Ein Migrationstest, der zweitausend Statusmails an echte Kunden schickt, ist eine wahre und häufige Geschichte.
Der Testplan
Testen Sie Kundenwege, keine Seiten. Sechs Wege decken das Wesentliche ab.
Eine vollständige Bestellung als nicht angemeldeter Besucher, mit echter Zahlung im Testmodus. Eine Bestellung mit bestehendem Konto und gespeicherter Adresse. Ein Warenkorb-Zugang von einer Kategorieseite mit aktiven Filtern. Eine interne Suche mit anschließendem Kauf. Eine Rücksendung oder eine Serviceanfrage. Und auf Verwaltungsseite das Anlegen eines Produkts mit Kombinationen sowie die Validierung einer Bestellung.
Jeder Weg muss auf Desktop und auf Mobilgerät durchgespielt werden. Rechnen Sie mit einem Tag für das Ganze, zu wiederholen nach jeder wesentlichen Korrektur.
Die Umstellung und die Zeit danach
Planen Sie die Migration außerhalb der Verkaufsspitzen, mit einem definierten und getesteten Zeitfenster für den Rückweg. Eine Sicherung, die nie zurückgespielt wurde, zählt nicht.
In den Tagen danach zählen drei Kontrollen. Die Fehlerprotokolle des Servers, die die Inkompatibilitäten zeigen, denen die Testumgebung nie begegnet ist. Kaputte Links und fehlende Bilder, denn ein Versionswechsel kann Bildpfade und umgeschriebene URLs betreffen. Und der Bestelleingang im Vergleich zum üblichen Niveau: ein plötzlicher Einbruch zeigt eine Blockade im Bestellprozess an, die niemand gemeldet hat.
Für diesen letzten Punkt hilft der Tote-Links-Prüfer für PrestaShop sowohl in der Abnahmephase als auch nach der Umstellung: Er findet kaputte interne Links und fehlende Bilder, die die Migration erzeugt haben kann, unter PrestaShop 8 wie unter PrestaShop 9.