PrestaShop 9 Kompatibilität: Alle unsere Module sind bereit

PrestaShop 9 ist da. Ist Ihr Modul-Stack bereit?

PrestaShop 9 brachte die umfassendste architektonische Überarbeitung seit der Einführung von Symfony in Version 1.7. Ich bereite unsere Module seit den frühen Alpha-Builds auf diese Version vor und habe dabei genau gelernt, was kaputt geht, was still und leise degradiert und was Shop-Betreiber prüfen müssen, bevor sie auch nur daran denken, auf „Upgrade" zu klicken.

Dies ist keine Changelog-Zusammenfassung. Dies ist der praktische Leitfaden, den ich mir gewünscht hätte, als ich zum ersten Mal eine PrestaShop-9-Beta öffnete und die Hälfte der Drittanbieter-Module in meinem Test-Shop 500-Fehler warfen. Ob Sie Shop-Betreiber sind und Ihren Modul-Stack evaluieren, freiberuflicher Entwickler und eine Kundenmigration vorbereiten, oder eine Agentur mit Dutzenden PrestaShop-Installationen — dieser Leitfaden führt Sie durch den vollständigen Kompatibilitäts-Audit-Prozess.

Was hat sich in PrestaShop 9 tatsächlich geändert (und warum bricht es Dinge kaputt)

Bevor Sie Ihre Module auditieren können, müssen Sie verstehen, was PrestaShop 9 auf architektonischer Ebene geändert hat. Das sind keine kosmetischen Updates. Es sind grundlegende Veränderungen, die jedes Modul betreffen, das mit dem Back Office, der Datenbankschicht oder dem Front-End-Theme interagiert.

Symfony 6.4: Die große Änderung

PrestaShop sprang von Symfony 4.4 auf Symfony 6.4. Das ist kein inkrementelles Update. Es ist ein Sprung über zwei Major-Versionen von Symfony, von denen jede eigene Deprecations und Entfernungen mit sich brachte. Für Modulentwickler ist die kritischste Konsequenz, wie Controller funktionieren.

In Symfony 4.4 konnten Sie $this->get('service_name') innerhalb von Controllern verwenden, um beliebige Services aus dem Container abzurufen. In Symfony 6.4 müssen Controller als Services mit korrekter Dependency Injection definiert werden. Der alte FrameworkBundleAdminController funktioniert in PrestaShop 9 noch, ist aber offiziell deprecated und wird in PrestaShop 10 entfernt. Jedes Modul, das diese Klasse erweitert, lebt auf geborgter Zeit.

Was das für Sie bedeutet: Wenn die Admin-Seiten eines Moduls heute unter PrestaShop 9 funktionieren, aber das Legacy-Controller-Pattern verwenden, könnten sie unter PrestaShop 10 komplett aufhören zu funktionieren. Sie wollen Module, die bereits zum PrestaShopAdminController mit Constructor Injection migriert haben.

Entfernte Bibliotheken, von denen Sie wahrscheinlich abhängen

PrestaShop 9 hat mehrere Bibliotheken aus dem Core entfernt, die Module zuvor kostenlos nutzten:

• Guzzle HTTP-Client wurde durch Symfonys HTTP-Client ersetzt. Jedes Modul, das externe API-Aufrufe über Guzzle macht, wird einen „class not found"-Fehler werfen, wenn es keine eigene Kopie mitbringt.
• SwiftMailer wurde durch Symfony Mailer ersetzt. Module, die direkt E-Mails senden (Bestellbenachrichtigungen, Alerts, Reports), müssen das neue Mailer-Interface verwenden.
• Tactician Command Bus wurde durch Symfony Messenger ersetzt. Module mit CQRS-Patterns über Tactician benötigen ein komplettes Rewrite ihrer Command/Query-Verarbeitung.

Das Tückische daran: Diese Fehler treten nicht immer sofort auf. Ein Modul kann sich einwandfrei installieren und seine Konfigurationsseite perfekt anzeigen, aber abstürzen, sobald es versucht, eine HTTP-Anfrage zu senden oder einen Command zu dispatchen. Das fangen Sie in einem schnellen „Lässt es sich installieren?"-Test nicht ab.

33 Hooks wurden entfernt

PrestaShop 9 hat 33 Hooks entfernt. Das ist kein Tippfehler. Dreiunddreißig Integrationspunkte, auf die Module zuvor angewiesen waren, existieren einfach nicht mehr. Die Entfernungen fallen in drei Kategorien:

• Legacy-Produktseiten-Hooks (die gesamte alte Produktbearbeitungsoberfläche wurde entfernt und nahm alle ihre Hooks mit): actionAdminProductsControllerXxx, actionAdminActivateAfter/Before, actionAdminDeactivateAfter/Before, actionAdminDeleteAfter/Before und actionAdminSortAfter/Before
• Login-Controller-Hooks (werden jetzt durch Symfony Security behandelt): actionAdminLoginControllerBefore, actionAdminLoginControllerLoginBefore/After, actionAdminLoginControllerForgotBefore/After und actionAdminLoginControllerResetBefore/After
• Layout-Hooks, die an den alten AdminController-Lebenszyklus gebunden waren (initHeader, initContent, initFooter, display), sind effektiv tot, weil PrestaShop 9 das Layout über Twig-Komponenten handhabt

Wenn ein Modul einen dieser Hooks registriert, stürzt es nicht ab, aber der Hook wird einfach nie ausgelöst. Das Modul verliert still und leise Funktionalität. Das ist wohl schlimmer als ein Absturz, weil Sie wochenlang nicht bemerken könnten, dass ein Feature aufgehört hat zu funktionieren.

PHP 8.1 Minimum, PHP 8.4 empfohlen

PrestaShop 9 erfordert mindestens PHP 8.1. Das schließt Shops aus, die noch PHP 7.4 oder 8.0 verwenden. Wichtiger noch: Module müssen PHP 8.1+-Features und striktere Typprüfung beherrschen. Funktionen, die zuvor gemischte Typen zurückgaben, benötigen jetzt explizite Return-Type-Deklarationen. Nullable-Parameter brauchen das ?-Prefix oder Union Types. Die Zeiten des losen PHP-Typings sind vorbei.

Ich teste alle unsere Module gegen PHP 8.1, 8.2, 8.3 und 8.4, weil jede Minor-PHP-Version neue Deprecation-Notices einführt, die Ihre Logs füllen können und in strikten Fehlerberichterstattungsumgebungen sichtbare Warnungen für Kunden verursachen.

Erweiterte Lagerverwaltung: Entfernt

Das gesamte erweiterte Lagerverwaltungssystem wurde aus PrestaShop 9 entfernt. Dies umfasst Lieferantenbestellungen, Lager und die alte Lagerverwaltungsoberfläche. Wenn eines Ihrer Module mit Lagerdaten, Lieferantenbestell-Hooks oder der API der erweiterten Lagerverwaltung interagiert, wird es kaputt gehen. Diese Entfernung betrifft auch Datenbanktabellen, sodass Module, die stockbezogene Tabellen direkt abfragen, SQL-Fehler erhalten.

Context Singleton Deprecation

Der Context-Singleton, den jeder PrestaShop-Entwickler kennt und liebt (oder toleriert), wird schrittweise ausgemustert. PrestaShop 9 führte dedizierte Context-Services ein: EmployeeContext, ShopContext, CurrencyContext, CountryContext, LanguageContext und andere. Module, die Context::getContext() verwenden, funktionieren weiterhin, aber Module nach modernen Praktiken sollten auf diese dedizierten Services umsteigen.

Übersetzungsfunktion escaped HTML nicht mehr

Dies ist eine subtile, aber gefährliche Änderung. Die trans()-Funktion in PrestaShop 9 escaped HTML-Entities nicht mehr automatisch. In früheren Versionen bot das Durchleiten von Benutzereingaben durch trans() quasi zufällig eine Schutzschicht gegen XSS. In PrestaShop 9 müssen Module explizit htmlspecialchars() auf alle dynamischen Inhalte anwenden, die an Übersetzungen übergeben werden. Module, die dies nicht aktualisieren, führen potenziell Sicherheitslücken ein.

Hummingbird Theme und Bootstrap 5

PrestaShop 9 liefert das Hummingbird-Theme als Standard aus, gebaut auf Bootstrap 5. PrestaShop 9.1 aktualisierte weiter auf Bootstrap 5.3.3. Für jedes Modul, das Front-End-Templates rendert, bedeutet das:

• Bootstrap 4 Klassennamen funktionieren nicht mehr (z.B. .no-gutters wird zu .g-0, .custom-checkbox wird zu .form-check)
• Data-Attribute sind mit Namespace versehen (data-toggle wird zu data-bs-toggle)
• jQuery ist in Hummingbird offiziell deprecated und wird in der nächsten Major-Theme-Version entfernt. Module, die auf jQuery für Front-End-Funktionalität angewiesen sind, brauchen einen Migrationspfad zu Vanilla JavaScript
• CSS-Selektoren basierend auf PrestaShop-spezifischen Klassen werden durch data-ps-*-Data-Attribute ersetzt

So auditieren Sie Ihre installierten Module: Ein Schritt-für-Schritt-Prozess

Jetzt, da Sie verstehen, was sich geändert hat, hier der systematische Prozess, den ich zur Bewertung der Modulkompatibilität verwende. Sie müssen kein Entwickler sein, um die meisten dieser Schritte zu befolgen.

Schritt 1: Bestandsaufnahme Ihrer Module

Gehen Sie in Ihr PrestaShop Back Office, navigieren Sie zu Module > Modulverwaltung, und exportieren oder screenshotten Sie Ihre vollständige Liste installierter Module. Notieren Sie für jedes Modul:

• Modulname und aktuelle Version
• Anbieter/Entwicklername
• Datum des letzten Updates
• Ob es ein kostenloses Modul, ein kostenpflichtiges Modul von PrestaShop Addons oder ein Drittanbieter-Modul ist

Kategorisieren Sie jedes Modul danach, wie kritisch es für Ihr Geschäft ist. Ein Zahlungs-Gateway-Modul ist kritisch. Ein Social-Sharing-Widget ist nice-to-have. Diese Priorisierung bestimmt Ihren Upgrade-Zeitplan.

Schritt 2: Kompatibilitätsaussagen der Anbieter prüfen

Suchen Sie für jeden Modulanbieter nach einer expliziten PrestaShop-9-Kompatibilitätsaussage. Hier erfahren Sie, worauf Sie achten müssen und was die Warnsignale sind:

Grüne Signale:

• Der Anbieter hat einen Blogbeitrag oder Changelog-Eintrag, der ausdrücklich PrestaShop 9.0 und 9.1 Kompatibilität erwähnt
• Die Modulversion wurde nach dem Release-Datum von PrestaShop 9 aktualisiert
• Der Anbieter erwähnt Tests gegen Symfony 6.4 und PHP 8.1+
• Abwärtskompatibilität mit PrestaShop 8.x wird aufrechterhalten (zeigt, dass er Multi-Versions-Support versteht)

Warnsignale:

• Keine Erwähnung von PrestaShop 9 irgendwo auf der Website des Anbieters
• Letztes Modul-Update war vor den PrestaShop 9 Alpha-Releases
• Die anderen Module des Anbieters wurden ebenfalls nicht aktualisiert (deutet auf eine aufgegebene Produktlinie hin)
• Die Modulbeschreibung erwähnt „PrestaShop 1.7 kompatibel" ohne Verweis auf 8.x oder 9.x

Schritt 3: Modulcode auf bekannte Problemmuster untersuchen

Wenn Sie grundlegende PHP-Kenntnisse haben oder Ihr Entwickler welche hat, öffnen Sie die Moduldateien und suchen Sie nach diesen spezifischen Mustern, die garantiert Probleme unter PrestaShop 9 verursachen:

Suchen Sie nach $this->get( in Admin-Controllern — Das ist das Legacy-Symfony-4.4-Servicezugriffsmuster. Es funktioniert unter PrestaShop 9, ist aber deprecated. Module, die dies verwenden, wurden nicht modernisiert.

Suchen Sie nach use GuzzleHttp — Wenn das Modul Guzzle importiert, es aber nicht in seinem eigenen Vendor-Verzeichnis einschließt, wird es unter PrestaShop 9 kaputt gehen, wo Guzzle aus dem Core entfernt wurde.

Suchen Sie nach Swift_ oder SwiftMailer — Gleiche Situation. SwiftMailer wurde aus dem Core entfernt.

Suchen Sie nach Tools::displayPrice — Dies wurde deprecated. Module sollten den Locale-Service zur Preisformatierung verwenden.

Suchen Sie nach data-toggle= in .tpl-Dateien — Bootstrap 4 Data-Attribute. Diese sollten data-bs-toggle= für Hummingbird-Kompatibilität sein.

Suchen Sie nach $.ajax oder $(document) in .js-Dateien — jQuery-Nutzung. Funktioniert noch im Classic-Theme, wird aber in Hummingbird kaputt gehen, wenn jQuery entfernt wird.

Schritt 4: Staging-Umgebung einrichten

Testen Sie Modulkompatibilität niemals auf Ihrem Live-Shop. Hier ist die Mindest-Staging-Konfiguration:

1. Klonen Sie Ihre Produktionsdatenbank in eine separate Datenbank (oder nutzen Sie die Staging-Funktion Ihres Hosting-Anbieters)
2. Installieren Sie PrestaShop 9 frisch oder verwenden Sie das Upgrade-Modul auf Ihrer geklonten Installation
3. Installieren Sie Ihre Module einzeln und prüfen Sie das Fehlerlog nach jeder Installation. Die Reihenfolge ist wichtig: Installieren Sie zuerst Zahlungs- und Versandmodule, dann SEO-Module, dann kosmetische Module
4. Testen Sie die Kernfunktionalität jedes Moduls, nicht nur „lädt die Konfigurationsseite". Geben Sie eine Testbestellung auf. Führen Sie einen Produktimport durch. Generieren Sie eine Sitemap. Was auch immer das Modul im Produktivbetrieb tatsächlich tut

Profi-Tipp: Überprüfen Sie Ihr PHP-Fehlerlog (/var/log/php_errors.log oder das Fehlerlog Ihres Hostings) nach jeder Modulinstallation. Viele Kompatibilitätsprobleme zeigen sich als PHP-Deprecation-Notices oder Warnungen statt als Totalabstürze. Die Warnung von heute ist der Fatal Error von morgen.

Schritt 5: Front-End-Rendering auf beiden Themes testen

Wenn Sie PrestaShop 9 mit dem neuen Hummingbird-Theme verwenden, testen Sie jedes Modul, das etwas im Front-End ausgibt. Achten Sie besonders auf:

• Checkout-Seiten-Modifikationen (Zahlungsmodulformulare, Versandauswahl, Adressvalidierung)
• Produktseiten-Widgets (Bewertungen, Wunschlisten, Größenratgeber, benutzerdefinierte Felder)
• Header- und Footer-Hooks (Mega-Menüs, Suchleisten, Warenkorbvorschauen)
• Kategorieseiten-Filter und Sortierung

Wenn Sie beim Classic-Theme bleiben, ist Ihr Front-End-Kompatibilitätsrisiko geringer, aber Bootstrap-5-Änderungen können immer noch Module betreffen, die eigenes CSS injizieren.

Was Sie Ihre Modulanbieter fragen sollten

Wenn Sie einen Modulanbieter wegen PrestaShop-9-Kompatibilität kontaktieren, fragen Sie nicht einfach „Ist es kompatibel?". Diese Frage bringt Ihnen eine Ja/Nein-Antwort, die falsch sein könnte. Stellen Sie stattdessen diese konkreten Fragen:

1. „Wurde das Modul auf PrestaShop 9.0 UND 9.1 getestet?" — Version 9.1 führte zusätzliche Breaking Changes ein (Bootstrap 5.3.3, jQuery-Deprecation, neue Hook-Änderungen). Nur auf 9.0 zu testen reicht nicht.
2. „Unterstützt das Modul mit derselben ZIP-Datei weiterhin PrestaShop 8.x?" — Wenn der Anbieter eine separate Version für PrestaShop 9 benötigt, ist das ein Wartungsaufwand für Sie. Ein gut gebautes Modul erkennt die Version intern.
3. „Haben Sie die deprecated Symfony-4.4-Patterns migriert?" — Wenn der Anbieter diese Frage nicht versteht, sagt Ihnen das etwas über seine technische Tiefe.
4. „Verwendet das Modul jQuery im Front-End?" — Falls ja, fragen Sie nach dem Migrationszeitplan zu Vanilla JavaScript, bevor Hummingbird die jQuery-Unterstützung einstellt.
5. „Welchen PHP-Versionstestbereich haben Sie?" — Sie wollen 8.1 bis 8.4 hören, nicht nur „PHP 8".

Das Upgrade-Entscheidungsframework

Basierend auf meiner Erfahrung beim Upgraden von Testumgebungen und der Unterstützung von Shop-Betreibern bei der Bewertung ihrer Bereitschaft, hier ein praktisches Framework für die Upgrade-Entscheidung:

Jetzt upgraden, wenn:

• Alle Ihre Module eine bestätigte PrestaShop-9-Kompatibilität von ihren Anbietern haben
• Sie bereits PHP 8.1+ verwenden
• Sie eine Staging-Umgebung haben, in der Sie den vollständigen Upgrade-Pfad getestet haben
• Ihr Theme entweder Classic, Hummingbird oder ein Child Theme von einem der beiden ist

3–6 Monate warten, wenn:

• Ein oder zwei nicht-kritische Module keine Kompatibilitätsbestätigung haben
• Ihr Theme ein stark angepasstes Drittanbieter-Theme ist (Theme-Anbieter hinken bei Major-Versions-Support oft hinterher)
• Sie auf die erweiterte Lagerverwaltung angewiesen sind (Sie müssen zuerst Ersatz-Workflows finden)

Noch nicht upgraden, wenn:

• Kritische Module (Zahlung, Versand, ERP-Integration) keine PrestaShop-9-Kompatibilitätsaussage haben
• Sie PHP 7.4 oder 8.0 verwenden (Sie brauchen zuerst ein PHP-Upgrade, was ein eigenes Projekt ist)
• Ihr Modulanbieter seit über einem Jahr nichts von sich hat hören lassen (das Modul könnte aufgegeben sein)

Wie wir unsere Module vorbereitet haben (eine Fallstudie aus der Praxis)

Bei mypresta.rocks habe ich Monate vor dem stabilen Release mit Tests gegen PrestaShop 9 Alpha-Builds begonnen. So sah der Prozess tatsächlich aus, weil ich denke, dass er lehrreich ist, um zu verstehen, was „kompatibel" wirklich bedeutet.

Phase 1: Automatisiertes Kompatibilitäts-Scanning

Ich führte statische Analysen über jedes Modul durch und suchte nach den oben beschriebenen Mustern: Legacy-Controller-Nutzung, entfernte Bibliotheksimporte, deprecated Funktionsaufrufe, Bootstrap-4-Klassen in Templates und jQuery-Nutzung in JavaScript-Dateien. Das ergab eine priorisierte Liste erforderlicher Änderungen.

Phase 2: Symfony 6.4 Migration

Jeder Admin-Controller wurde auf Service-Container-Zugriffsmuster überprüft. Wo Module $this->get() verwendeten, migrierten wir zu Constructor Injection. Wo Module den deprecated Base-Controller erweiterten, aktualisierten wir die Elternklasse. Dies war die zeitaufwändigste Phase, weil sie die Kernarchitektur jedes admin-seitigen Moduls berührt.

Phase 3: Hook-Audit

Wir glichen jede Hook-Registrierung in jedem Modul mit der Liste der 33 entfernten Hooks ab. Wo Module entfernte Hooks verwendeten, migrierten wir entweder zu Ersatz-Hooks oder implementierten versionsbedingte Hook-Registrierung, die automatisch den korrekten Hook für die erkannte PrestaShop-Version verwendet.

Phase 4: Multi-Versions-Tests

Jedes Modul wurde auf PrestaShop 1.7.6, 1.7.7, 1.7.8, 8.0, 8.1, 9.0 und 9.1 getestet. Auf jeder Version testeten wir mit PHP 8.1, 8.2, 8.3 und 8.4. Eine einzige Modul-ZIP-Datei funktioniert über all diese Kombinationen, weil das Modul die PrestaShop-Version zur Laufzeit erkennt und sein Verhalten entsprechend anpasst.

Das bedeutet „abwärtskompatibel" in der Praxis. Es sind nicht zwei separate Builds. Es ist eine Codebasis, die Versionsunterschiede intern handhabt.

Phase 5: Front-End-Theme-Tests

Jedes Modul mit Front-End-Ausgabe wurde auf dem Classic-Theme und dem Hummingbird-Theme getestet. Bootstrap-Klassennamen, Data-Attribute und JavaScript wurden auf beiden verifiziert. Wo Template-Unterschiede erforderlich waren, verwendeten wir PrestaShops eingebaute Versionserkennung, um das passende Template zu laden.

Das Ergebnis: Alle mypresta.rocks Module sind vollständig kompatibel mit PrestaShop 9.0 und 9.1 und erhalten gleichzeitig die Abwärtskompatibilität mit PrestaShop 1.7.6+ und allen 8.x-Versionen. Keine separaten Downloads, keine speziellen Installationsschritte, keine „PrestaShop 9 Edition"-Preise.

Häufige Probleme nach dem Upgrade und wie Sie sie beheben

Auch mit kompatiblen Modulen könnten Sie nach dem Upgrade auf PrestaShop 9 auf diese Probleme stoßen:

Weißer Bildschirm / 500-Fehler nach Modulinstallation

Wird meist durch eine fehlende Composer-Abhängigkeit verursacht. Prüfen Sie Ihr PHP-Fehlerlog auf „Class not found"-Fehler. Die Lösung ist entweder das Aktualisieren des Moduls (wenn der Anbieter eine neue Version hat) oder das manuelle Hinzufügen der fehlenden Bibliothek in das Vendor-Verzeichnis des Moduls.

Admin-Seiten laden, aber Features fehlen

Das ist das Problem der stillen Hook-Entfernung. Das Modul wurde erfolgreich installiert, aber seine Hooks werden unter PrestaShop 9 nicht mehr ausgelöst. Prüfen Sie die Hook-Registrierungen des Moduls gegen die Liste der entfernten Hooks. Kontaktieren Sie den Anbieter für eine aktualisierte Version, die die Ersatz-Hooks verwendet.

Front-End-Styling kaputt auf Hummingbird

Bootstrap 4 zu 5 Klassennamen-Änderungen. Das Modul funktioniert auf Classic, sieht aber auf Hummingbird kaputt aus. Das erfordert Template-Updates vom Modulanbieter. Als vorübergehende Lösung können Sie zum Classic-Theme wechseln, während Sie auf das Update des Anbieters warten.

JavaScript-Fehler in der Browser-Konsole

Oft verursacht durch jQuery-Abhängigkeit in einer Hummingbird-Umgebung. Prüfen Sie die Browser-Entwicklerkonsole (F12) auf „$ is not defined"- oder „jQuery is not defined"-Fehler. Die langfristige Lösung ist Vanilla JavaScript, aber kurzfristig können Sie jQuery manuell in die Assets Ihres Themes einbinden.

E-Mail-Benachrichtigungen funktionieren nicht mehr

Wenn ein Modul E-Mails direkt über SwiftMailer statt über PrestaShops Mail-Funktion sendet, wird es unter PrestaShop 9 kaputt gehen, wo SwiftMailer durch Symfony Mailer ersetzt wurde. Kontaktieren Sie den Anbieter für ein Update.

PrestaShop 9.1: Zusätzliche Änderungen im Blick

PrestaShop 9.1 führte eigene Änderungen zusätzlich zu 9.0 ein. Wenn Sie direkt auf 9.1 upgraden (empfohlen, da es die neueste stabile Version ist), beachten Sie diese zusätzlichen Kompatibilitätsfaktoren:

• Theme::getDefaultTheme() gibt nicht mehr den fest kodierten String „classic" zurück. Module, die annahmen, das Standard-Theme sei Classic, müssen aktualisiert werden.
• Der displaySearch-Hook wurde aus Hummingbird entfernt, weil er Konflikte auf 404-Seiten verursachte. Module, die displaySearch für Front-End-Suchanpassung verwenden, müssen alternative Hooks nutzen.
• D3 und NVD3 Charting-Bibliotheken wurden auf neuere Versionen aktualisiert. Dashboard-Widgets, die diese Bibliotheken verwenden, könnten falsch gerendert werden.
• JavaScript-Selektoren wurden zur data-ps-*-Konvention migriert, die klassenbasierte Selektoren ersetzt. Module, die querySelector mit PrestaShop-spezifischen Klassennamen verwenden, könnten die falschen Elemente ansprechen.

Ihre Pre-Upgrade-Checkliste

Drucken Sie diese aus, hängen Sie sie an die Wand, und upgraden Sie nicht, bevor jeder Punkt abgehakt ist:

1. Bestandsaufnahme aller installierten Module mit Anbieternamen und aktuellen Versionen
2. Website jedes Anbieters auf PrestaShop-9-Kompatibilitätsaussagen prüfen
3. Alle Module auf ihre neuesten Versionen aktualisieren (auch vor dem PrestaShop-Upgrade)
4. Staging-Umgebung mit einer Kopie Ihrer Produktionsdatenbank einrichten
5. PrestaShop 9.1 auf dem Staging installieren
6. Module einzeln installieren und Fehlerlogs nach jedem Modul prüfen
7. Kernfunktionalität jedes Moduls testen (nicht nur „lädt die Konfigurationsseite")
8. Front-End-Rendering auf Ihrem aktiven Theme testen
9. Eine komplette Testbestellung durch den Checkout durchführen
10. PHP-Fehlerlogs auf Deprecation-Warnungen prüfen
11. E-Mail-Versand aller Module überprüfen, die Benachrichtigungen senden
12. Alles sichern: Datenbank, Dateien und Konfiguration
13. Das Upgrade während verkehrsschwacher Stunden planen
14. Ihre PrestaShop-8.x-Sicherung mindestens 30 Tage nach dem Upgrade verfügbar halten

Schlusswort

PrestaShop 9 ist eine signifikante Verbesserung. Symfony 6.4 bringt bessere Performance, moderne PHP-Praktiken und eine wartbarere Architektur. Das Hummingbird-Theme ist schneller und zugänglicher als Classic. Die neue Admin-API eröffnet Möglichkeiten, die vorher nicht verfügbar waren.

Aber nichts davon spielt eine Rolle, wenn Ihre Module beim Upgrade kaputt gehen. Nehmen Sie sich die Zeit für ein ordentliches Audit. Verwenden Sie eine Staging-Umgebung. Machen Sie Ihre Anbieter für explizite Kompatibilitätsaussagen verantwortlich, nicht für vage „sollte funktionieren"-Antworten.

Wenn Sie Module suchen, die rigoros über PrestaShop 1.7.6 bis 9.1 getestet wurden, schauen Sie sich den mypresta.rocks Modulkatalog an. Jedes Modul wird als einzelne ZIP-Datei ausgeliefert, die über alle unterstützten Versionen funktioniert, und die PrestaShop-9-Kompatibilität ist in jeder Lizenz enthalten — nicht als separates Upgrade verkauft.

Haben Sie Fragen zu Ihrem spezifischen Upgrade-Szenario? Kontaktieren Sie uns, und ich helfe Ihnen bei der Bewertung Ihres Modul-Stacks.