Neuigkeiten & Updates

PrestaShop-9-Kompatibilität: Alle unsere Module sind bereit

David Miller Veröffentlicht: 22. Feb. 2026 Aktualisiert: Neuigkeiten & Updates

279 Aufrufe 20 Min. Lesezeit

Jedes Modul, das wir ausliefern, läuft auf PrestaShop 9. Das war dafür nötig.

Zuletzt geprüft im Juni 2026. Version 9.1.0 ist seit dem 23. März 2026 verfügbar, auf Symfony 6.4 LTS, PHP 8.1–8.5, mit Hummingbird (Bootstrap 5.3) als Standardtheme für Neuinstallationen. Wir betreiben mypresta.rocks auf 9.1.3 und haben unsere 150+ Module bis 9.1 getestet.

Wir haben Anfang 2024 begonnen, unseren Katalog gegen die Alphas von PrestaShop 9 neu abzusichern. Als die stabile 9.0-Version erschien, ließ unsere interne CI bereits jedes Modul-ZIP durch sieben PrestaShop-Versionen und vier PHP-Versionen laufen, bevor wir auch nur eine Zeile zusammenführten. Heute lässt sich jedes Modul in unserem Katalog mit 150+ Modulen aus demselben ZIP auf PS 9.0 und 9.1 installieren und betreiben wie auf 8.x, 1.7 und 1.6. Eine Codebasis, Laufzeit-Erkennung der Version, keine Preisaufschläge für eine „PrestaShop-9-Edition“.

Ein Code-Editor auf einem Bildschirm, der Softwarekompatibilitätstests illustriert

Das ist die Kurzfassung. Der Rest dieses Beitrags ist der Teil, den die meisten Ankündigungen nach dem Muster „Wir unterstützen PS 9!“ auslassen: was bei der Migration tatsächlich kaputtging, was wir nur gefunden haben, weil wir in echten Shops testen, und welche Fragen Sie anderen Anbietern stellen sollten, bevor Sie deren Kompatibilitätsversprechen vertrauen.

Was PrestaShop 9 tatsächlich geändert hat

Wenn Sie nur die Zusammenfassung im PrestaShop-Blog gelesen haben, könnte man meinen, PS 9 sei ein aufgeräumtes Symfony-Upgrade. Ist es nicht. Es ist das einschneidendste Release seit 1.7 Symfony überhaupt eingeführt hat, und die Umbrüche sitzen genau in den Teilen des Frameworks, die Module am häufigsten berühren.

Symfony 4.4 auf 6.4, zwei Hauptversionen in einem Sprung

Hier scheitern die meisten Drittanbieter-Module. In 4.4 konnte man in einem Admin-Controller $this->get('service_name') schreiben und sich praktisch alles aus dem Container holen. In 6.4 funktioniert dieses Muster noch (PrestaShop hat eine Kompatibilitätsschicht behalten), aber die Basisklasse, auf der es beruht, FrameworkBundleAdminController, ist offiziell veraltet und für die Entfernung in PrestaShop 10 vorgesehen.

Übersetzt heißt das: Wenn die Admin-Seiten eines Moduls heute auf PS 9 rendern, es aber weiterhin FrameworkBundleAdminController erweitert, hat dieses Modul ein bekanntes Ablaufdatum. Wir haben jeden unserer Admin-Controller auf PrestaShopAdminController mit sauberer Constructor Injection umgestellt. Das ist der langsamste Teil der Migration, und es ist der Teil, den man nicht überspringen kann.

Bibliotheken, die der Core nicht mehr mitliefert

PrestaShop 9 hat drei Bibliotheken entfernt, die Module früher kostenlos aus dem vendor/ des Cores mitbenutzen konnten:

Guzzle, ersetzt durch den HTTP-Client von Symfony. Jedes Modul, das use GuzzleHttp\Client verwendet und keine eigene Kopie mitliefert, endet in einem Fatal Error wegen einer nicht gefundenen Klasse, sobald es einen HTTP-Aufruf ausführen will.
SwiftMailer, ersetzt durch Symfony Mailer. Module, die E-Mails direkt über Swift versenden, bekommen nicht nur eine Deprecation-Meldung; sie brechen fatal ab.
Tactician command bus, ersetzt durch Symfony Messenger. Wenn ein Modul CQRS über Tactician genutzt hat, müssen die Command-/Query-Handler neu geschrieben werden.

Der Punkt, der viele erwischt: Diese Fehler zeigen sich nicht bei der Installation. Das Modul wird geladen, die Konfigurationsseite rendert sauber, und dann stürzt es beim ersten Cron-Lauf oder beim ersten Kundenereignis ab, das den E-Mail-Versand auslöst. Genau so haben wir in der PS-9-Alpha zwei eigene Module gefunden, sie installierten sauber, sahen im Backoffice gesund aus und flogen erst um 3 Uhr morgens auseinander, als ein Cron zur Bestands-Synchronisierung lief.

33 Hooks wurden entfernt

Einige Hooks wurden entfernt; die unten aufgeführten AdminController-Lifecycle-Hooks werden auf Legacy-Controllern weiterhin ausgelöst, von neuen Symfony-Admin-Seiten jedoch übersprungen. Die Entfernungen bündeln sich in drei Gruppen:

Legacy-Hooks für Admin-Produkte. Der gesamte alte Produkteditor ist verschwunden und hat seine Hooks mitgenommen (actionAdminProductsControllerXxx, actionAdminActivateAfter/Before, actionAdminDeactivateAfter/Before, actionAdminDeleteAfter/Before, actionAdminSortAfter/Before)
Hooks für die Admin-Anmeldung, jetzt von Symfony Security behandelt (actionAdminLoginControllerBefore, actionAdminLoginControllerLogin/Forgot/Reset Before/After)
Lifecycle-Hooks des AdminControllers. initHeader, initContent, initFooter, display werden weiterhin auf Legacy-Controllern ausgelöst, die von LegacyController gekapselt werden, aber neue Symfony-Admin-Seiten überspringen sie vollständig. Wenn Ihr Modul darauf angewiesen ist, testen Sie jede Admin-Seite, auf der es erscheint.

In der Praxis ist das schlimmer als ein Absturz: Ein Modul registriert sich auf einen entfernten Hook, die Installation klappt, der Hook feuert einfach nie, und die Funktion hört still auf zu arbeiten. Eines unserer eigenen Module war in genau diesem Zustand zwei Wochen lang auf einem Staging-Shop, bevor uns auffiel, dass ein Benachrichtigungs-Badge im Admin-Bereich leise verschwunden war.

PHP 8.1 als Minimum, und wir testen bis 8.4

PS 9 streicht PHP 8.0 und älter. Wir testen jedes Modul gegen 8.1, 8.2, 8.3 und 8.4, weil jede Minor-Version ihren eigenen Satz an Deprecations hat, und eine Deprecation in 8.3, die nur Logs füllt, ist in 8.4 oft schon ein harter Fehler. Sie in der CI auf 8.4 zu finden, ist günstiger, als sie erst zu entdecken, wenn ein Hoster den Shop eines Kunden über Nacht auf 8.4 anhebt.

Advanced Stock Management ist weg

Das gesamte Teilsystem (Lieferbestellungen, Lager, die ASM-Admin-Oberfläche) wurde in PS 9 entfernt. Auch die Datenbanktabellen sind weg, sodass Module, die ps_supply_order* oder ps_warehouse* direkt abgefragt haben, SQL-Fehler werfen und nicht nur PHP-Warnungen. Zwei unserer eigenen Module (mprwarehouserevolution und mprstockorder) behandeln Lagerdaten bewusst unabhängig von ASM, weil wir nie darauf vertraut haben, dass ASM überlebt. Diese Wette hat sich ausgezahlt.

Der Context-Singleton wird ausgemustert

PS 9 führt dedizierte Kontext-Services ein: EmployeeContext, ShopContext, CurrencyContext, CountryContext, LanguageContext. Context::getContext() funktioniert weiterhin und wird es noch eine Weile tun, aber es ist jetzt ein Code Smell. Wir migrieren ihn opportunistisch, wenn wir ohnehin in einer Datei etwas reparieren, stellen wir auf den passenden dedizierten Service um.

trans() escaped HTML nicht mehr

Dieser Punkt ist gefährlich, weil er unsichtbar ist. In PS 8 und älter hat die Funktion trans() HTML-Entities als Nebeneffekt escaped. Viel Modulcode hat sich unbeabsichtigt darauf als XSS-Schutz verlassen, ohne dass es jemand gemerkt hat. In PS 9 müssen Sie dynamische Inhalte ausdrücklich mit htmlspecialchars() behandeln, bevor Sie sie an trans() übergeben. Module, die das nicht tun, sitzen jetzt auf potenziellen XSS-Lücken, obwohl sie jahrelang problemlos liefen.

Hummingbird, Bootstrap 5 und die jQuery-Uhr

PS 9.1 liefert Hummingbird als Standardtheme für Neuinstallationen aus, auf Bootstrap 5.3.3 (PS 9.0 nutzte Bootstrap 5, aktualisierte Shops behalten ihr bestehendes Theme). Für Module mit Frontend-Ausgabe bedeutet das:

Bootstrap-4-Utility-Klassen sind weg (.no-gutters ist .g-0, .custom-checkbox ist .form-check)
Data-Attribute haben jetzt einen Namensraum (data-toggle ist data-bs-toggle)
jQuery ist in Hummingbird offiziell veraltet und hat ein Ablaufdatum. Wir haben die Frontend-JS unserer Module für Kasse, Performance und Produkt-Tabs bereits auf Vanilla JS umgeschrieben, teils, um der Frist zuvorzukommen, teils, weil Hummingbirds Kassenlayout die DOM-Thrash-Muster von jQuery bestraft
PrestaShop-spezifische Klassenselektoren werden durch data-ps-*-Attribute ersetzt, wenn Ihr CSS oder JS auf .cart-block zielt, müssen Sie mit einer Anpassung rechnen

So auditieren Sie Ihren bestehenden Modul-Stack

Die meisten Shops, die wir migrieren, laufen nicht nur mit unseren Modulen, sie nutzen einen Stack aus fünfzehn bis vierzig Modulen von einem Dutzend Anbietern, und unsere Module sind fünf davon. So gehen wir bei jeder Kundenmigration vor.

Schritt 1: Ehrlich inventarisieren

Module → Modulmanager. Exportieren Sie die Liste. Notieren Sie für jedes Modul: Name, aktuelle Version, Anbieter, Datum des letzten Updates und wie kritisch es ist. Ein Zahlungs-Gateway ist kritisch; ein Social-Share-Widget ist Dekoration. Diese Kritikalität bestimmt Ihren Zeitplan, nicht die alphabetische Reihenfolge.

Schritt 2: Lesen Sie das Changelog des Anbieters, nicht die Überschrift

„PrestaShop-9-kompatibel“ auf einer Startseite bedeutet nichts. Was Sie suchen, ist ein Changelog-Eintrag nach dem öffentlichen Release von PS 9, der ausdrücklich Arbeiten an Symfony 6.4, Tests mit PHP 8.1+ oder den Ersatz entfernter Hooks erwähnt. Wenn das jüngste Update des Anbieters von 2023 stammt und der Marketingtext immer noch mit „PrestaShop-1.7-kompatibel“ beginnt, ist das Modul wahrscheinlich verlassen und die Website hat es nur noch nicht nachgezogen.

Schritt 3: Grep über den Modulcode laufen lassen

Wenn Sie einen Entwickler haben (oder selbst auf der Kommandozeile arbeiten), entpacken Sie das Modul und suchen Sie nach Mustern, die geprüft werden müssen, darunter veraltete, aber noch funktionierende Service-Zugriffe und Abhängigkeiten, die Fehler verursachen können:

# Legacy Symfony 4.4 service access
grep -rn '\$this->get(' modules/yourmodule/

# Removed core libraries
grep -rn 'use GuzzleHttp' modules/yourmodule/
grep -rn 'Swift_\|SwiftMailer' modules/yourmodule/
grep -rn 'League\\Tactician' modules/yourmodule/

# Deprecated price formatting (removed in PS 9.0)
grep -rn 'Tools::displayPrice' modules/yourmodule/

# Bootstrap 4 data attributes
grep -rn 'data-toggle=' modules/yourmodule/views/templates/

# jQuery usage in front-end JS
grep -rn '\$.ajax\|\$(document)' modules/yourmodule/views/js/

Ein Treffer auf use GuzzleHttp ohne eine composer.json, die Guzzle im eigenen vendor-Ordner des Moduls mitliefert, ist ein bestätigter Absturz auf PS 9. Ein Treffer auf Tools::displayPrice ist ein harter Fatal. Diese Methode wurde entfernt, nicht nur als veraltet markiert. Intern pflegen wir ein kleines prestashop-compat-Paket, das solche Fälle für unsere Module kapselt; bei Drittanbieter-Modulen ohne diesen Schutz stirbt der Aufruf.

Schritt 4: Staging, das die Produktion wirklich spiegelt

Testen Sie Kompatibilität niemals im Live-Shop. Unser minimales Staging-Rezept:

Klonen Sie die Produktionsdatenbank in eine separate Datenbank (die meisten ordentlichen Hoster bieten dafür einen One-Click-Ablauf)
Installieren Sie PS 9.1 darauf. Direkt auf 9.1, nicht über 9.0, denn 9.1 ist ohnehin dort, wo Sie am Ende landen
Installieren Sie Module in Abhängigkeitsreihenfolge: Zahlung und Versand zuerst, dann SEO/Marketing, dann Kosmetik. So blockiert ein Absturz eines schweren Moduls nicht Ihre Möglichkeit, die leichteren zu testen
Beobachten Sie nach jeder Installation das PHP-Fehlerlog und das PrestaShop-Log unter var/logs/. Die meisten Kompatibilitätsprobleme sind zuerst Deprecation-Hinweise und beim nächsten Minor-Release Fatals, tun Sie Warnungen nicht ab
Testen Sie die eigentliche Aufgabe des Moduls, nicht nur „öffnet sich die Konfigurationsseite“. Geben Sie eine echte Testbestellung auf. Führen Sie einen Import aus. Generieren Sie eine echte Sitemap. Eine rendernde Konfigurationsseite beweist fast nichts

Die wirkungsvollste Gewohnheit, die wir übernommen haben: tail -f var/logs/* in einem Terminal laufen lassen und parallel im Backoffice herumklicken. Deprecation-Rauschen ist der Frühindikator für Brüche in der nächsten Version. Wenn ein Modul dieses Log auf PS 9.1 füllt, ist es genau das Modul, das auf 9.2 fatal abbrechen wird.

Schritt 5: Frontend-Smoke-Test auf dem Theme, das Sie wirklich einsetzen

Wenn Sie auf Hummingbird wechseln, braucht jedes Modul mit Frontend-Ausgabe eine visuelle Prüfung auf dem echten Theme, nicht auf Classic in einem Test-Admin. Die Stellen, an denen wir fast immer Brüche finden:

Kasse, Zahlungsformulare, Versanddienstleister-Blöcke, Adressvalidierung, alles, was in die Bestellübersicht injiziert wird
Produktseiten, Bewertungen, Wunschlisten, Größentabellen, Blöcke für benutzerdefinierte Felder
Header/Footer. Mega-Menüs und Such-Dropdowns sind bei der Migration auf Bootstrap 5 besonders fragil
Kategorieseiten-Filter und Sortiersteuerungen

Wenn Sie bei Classic bleiben, ist Ihr Risiko geringer, aber es ist nicht null, weil Bootstrap 5 trotzdem im Admin-Bereich ankommt und jedes Modul, das CSS zwischen Front- und Backoffice teilt, sich weiterhin danebenbenehmen kann.

Die Fragen, die sich bei einem Anbieter lohnen

„Ist Ihr Modul mit PrestaShop 9 kompatibel?“ ist eine Ja/Nein-Frage, die in 100 % der Fälle „ja“ zurückgibt, oft fälschlicherweise. Das sind die Fragen, die wir Anbietern stellen, wenn wir ihre Module für den Stack eines Kunden prüfen:

Ist das Modul auf 9.0 und 9.1 getestet? 9.1 brachte Bootstrap 5.3.3, entfernte displaySearch und überarbeitete die data-ps-*-Selektor-Konvention. Nur auf 9.0 zu testen, ist halbe Arbeit.
Ist es dasselbe ZIP für 8.x und 9.x? Wenn Sie für PS 9 einen separaten Download brauchen, ist das bei jedem Shop mit mehreren Versionen eine Wartungsfalle. Single-ZIP-Module mit Laufzeit-Erkennung der Version sind der richtige Weg.
Sind Sie von FrameworkBundleAdminController wegmigriert? Wenn der Entwickler die Frage nicht erkennt, haben Sie etwas Wichtiges gelernt.
Braucht die Frontend-JS noch jQuery? Im Moment in Ordnung, aber fragen Sie nach dem Migrationsplan. Hummingbird wird jQuery entfernen, und Sie möchten dann nicht die letzte Priorität eines Anbieters sein.
Wie sieht die PHP-Testmatrix aus? Die Antwort, die Sie hören wollen, ist „8.1 bis 8.4“, nicht „PHP 8“.

Wann Sie upgraden sollten und wann Sie warten sollten

Gehen Sie jetzt los, wenn Ihre kritischen Module ausdrücklich mit PS 9.1 kompatibel sind, Sie bereits auf PHP 8.1+ laufen, eine funktionierende Staging-Kopie haben und Ihr Theme Classic, Hummingbird oder ein Child-Theme davon ist.

Warten Sie drei bis sechs Monate, wenn ein oder zwei nicht zwingend nötige Module keine Kompatibilitätsbestätigung haben, Ihr Theme ein stark angepasstes kostenpflichtiges Theme ist (Theme-Anbieter hinken hinterher. Wir haben Lücken von 18 Monaten gesehen), oder Sie auf Advanced Stock Management angewiesen sind und noch keinen Ersatz festgelegt haben.

Upgraden Sie nicht, wenn ein kritisches Modul (Zahlung, Versand, ERP-Synchronisierung) keine Aussage zu PS 9 hat und der Anbieter seit einem Jahr nichts ausgeliefert hat, Sie noch auf PHP 7.4 oder 8.0 sind (das ist ein eigenes Projekt, erledigen Sie es zuerst), oder Ihr Shop umfangreiche Agentur-Anpassungen enthält, die noch nicht auf PS 9 getestet wurden.

Wie wir unsere 150+ Module tatsächlich auf PS 9 gebracht haben

Das lohnt sich im Detail, denn „wir unterstützen PrestaShop 9“ bedeutet bei verschiedenen Anbietern Unterschiedliches, und dieser Unterschied zählt, wenn Sie ein Modul im Live-Shop einsetzen.

Qualitätssicherungstests für Module zur Gewährleistung der PrestaShop-9-Kompatibilität

Phase 1: Statische Analyse über den gesamten Katalog

Wir haben einen eigenen Scanner über den Quellcode jedes Moduls laufen lassen und nach den oben genannten Mustern gesucht: Legacy-Controller-Nutzung, Guzzle-/Swift-/Tactician-Imports, Tools::displayPrice, Bootstrap-4-Markup, jQuery-Abhängigkeiten. Das Ergebnis war eine nach Risiko sortierte Arbeitsliste pro Modul. Wir wollten uns nicht darauf verlassen, uns „zu merken“, welches Modul welche Korrektur braucht.

Phase 2: Migration der Controller auf Symfony 6.4

Jeder Admin-Controller, der den Service-Container berührte, wurde von $this->get() auf Constructor Injection umgestellt. Jeder Controller, der die veraltete Basisklasse erweiterte, wurde auf PrestaShopAdminController migriert. Das ist die langsame Phase, sie berührt das Rückgrat jedes adminseitigen Moduls, und es gibt keine Abkürzung.

Phase 3: Hook-Audit und Ersatz

Wir haben jeden registerHook()-Aufruf im gesamten Katalog mit der Liste der in PS 9 entfernten Hooks abgeglichen. Wo ein Hook weg war, haben wir entweder auf den Ersatz migriert oder eine versionsabhängige Registrierung in den Installationsskripten ergänzt, sodass ein Modul, das auf PS 8.x installiert wird, weiterhin den alten Hook nutzt, und dasselbe ZIP auf PS 9 den neuen.

Phase 4: Gemeinsame Kompatibilitätsschicht

Die Methoden, die in künftigen Minor-Releases am ehesten entfernt werden, liegen hinter Wrappern in einem gemeinsamen Paket (prestashop-compat). Tools::displayPrice ist das offensichtliche Beispiel. Über alle 150+ Module hinweg ist es jetzt \MyPrestaRocks\Compat\PriceFormatter::format(), und der Wrapper erkennt die PS-Version und ruft die richtige API auf. Wenn PS 9.2 etwas anderes entfernt, aktualisieren wir den Wrapper einmal, synchronisieren, und jedes Modul ist abgedeckt.

Phase 5: Matrix-Tests in der CI

Jedes Modul-ZIP wird über PrestaShop 1.7.6, 1.7.7, 1.7.8, 8.0, 8.1, 9.0 und 9.1 getestet, und auf jeder Version gegen PHP 8.1, 8.2, 8.3 und 8.4. Wir lassen das auf dedizierten Docker-Containern (ps176-dev, ps178-dev, ps8-dev, ps9-dev) in unserer eigenen Infrastruktur laufen und starten bei Bedarf temporäre Container für bestimmte Minor-Versionen. Ein einziges Modul-ZIP funktioniert auf jeder Kombination, weil das Modul zur Laufzeit auf _PS_VERSION_ verzweigt, nicht weil wir mehrere Builds ausliefern.

Phase 6: Prüfung mit Hummingbird- und Classic-Theme

Jedes Modul mit Frontend-Ausgabe wird vor der Veröffentlichung auf beiden Themes gerendert. Wo Templates abweichen mussten (ein paar mussten es, meist rund um data-bs-*-Attribute und Formular-Komponenten), nutzen wir PrestaShops Versionshelfer, um das richtige Template auszuwählen. Der Händler sieht davon nichts; seine views/templates/hook/*.tpl funktionieren einfach auf dem jeweils genutzten Theme.

Wo wir ehrlich geblieben sind

Einige unserer Module berühren Bereiche, die PS 9 auf Framework-Ebene neu gestaltet hat, Backoffice-Produkt-Tabs, Multi-Shop-Kontext, AdminAPI-Bridges. Für diese Module haben wir jeden einzelnen Funktionspfad auf PS 9.0 und 9.1 manuell getestet, bevor wir das Kompatibilitätsflag gesetzt haben. Wir behaupten Kompatibilität nicht, weil die Kategorie sicher aussieht; wir behaupten sie, weil das Modul auf der Version, für die wir es behaupten, Ende zu Ende gelaufen ist.

Das Ergebnis: Jedes Modul im mypresta.rocks-Katalog lässt sich aus demselben ZIP auf PS 9.0 und 9.1 installieren und betreiben, das auch auf 8.x, 1.7 und 1.6 läuft. Keine separate Edition, keine Migrationsgebühr.

Was nach einem erfolgreichen Upgrade schiefgehen kann

Selbst mit vom Anbieter bestätigten Modulen sehen wir nach Upgrades typischerweise dieses Muster, ungefähr in der Reihenfolge, in der die Probleme auftreten.

500-Fehler nach der Installation eines einzelnen Moduls

Fast immer fehlt eine Composer-Abhängigkeit im eigenen vendor-Ordner des Moduls. Das PHP-Fehlerlog meldet dann „Class not found“ mit einem erkennbaren Namen, meistens GuzzleHttp\Client, Swift_Mailer oder eine Symfony-Messenger-Klasse. Aktualisieren Sie entweder das Modul oder legen Sie, wenn der Anbieter langsam ist, die fehlende Bibliothek manuell in vendor/ des Moduls ab (wir haben das in Kundenshops gemacht, um sie am Laufen zu halten, während wir auf eine echte Korrektur warteten).

Admin-Seite lädt, Funktion ist still tot

Das Problem mit den entfernten Hooks. Das Modul wurde installiert, die Konfigurationsseite rendert, aber der Hook, auf den sich die Funktion verlassen hat, feuert nie. Prüfen Sie install() des Moduls gegen die Liste der in PS 9 entfernten Hooks. Die Korrektur ist ein Anbieter-Update, kein clientseitiger Workaround bringt einen entfernten Hook zurück.

Frontend sieht auf Hummingbird kaputt aus, auf Classic aber sauber

Bootstrap-Klassen sind von 4 auf 5 auseinandergewandert. Die Templates des Moduls verwenden .no-gutters, .custom-checkbox, data-toggle oder anderes BS4-Markup. Vorübergehender Workaround: den Shop auf das Classic-Theme umstellen, während Sie warten. Echte Korrektur: Template-Update des Anbieters.

JavaScript-Fehler in der Konsole

Entweder wird jQuery erwartet und ist nicht geladen, oder Selektoren zielen auf alte Klassennamen, die zu data-ps-* gewandert sind. $ is not defined in der Konsole ist der klare Hinweis. Kurzfristig können Sie jQuery manuell im Theme laden; langfristig braucht das Modul Vanilla JS.

E-Mails werden einfach nicht mehr gesendet

Das Modul ruft SwiftMailer direkt auf, statt über PrestaShops Mail::Send() zu gehen. PS 9 hat keinen SwiftMailer mehr, den es instanziieren könnte. Dafür gibt es keine clientseitige Korrektur; das Modul muss auf Symfony Mailer aktualisiert werden.

PrestaShop 9.1, die Extras, die Sie kennen sollten

Wenn Sie 9.0 überspringen und direkt auf 9.1 gehen (vernünftig, dort landen Sie ohnehin), bringt 9.1 zusätzlich zu 9.0 eigene Breaking Changes mit:

Theme::getDefaultTheme() kodiert „classic“ nicht mehr fest. Module, die für ihre Fallback-Logik davon ausgingen, dass Classic der Standard ist, verhalten sich falsch.
Der Hook displaySearch ist aus Hummingbird verschwunden, er verursachte Rendering-Konflikte auf 404-Seiten. Module, die sich für Frontend-Suchanpassungen in displaySearch einklinken, brauchen einen anderen Hook.
D3- und NVD3-Versionen wurden angehoben. Wenn ein Dashboard-Widget an eine bestimmte D3-API gebunden war, kann es auf 9.1 falsch rendern.
JavaScript-Selektoren wanderten von klassenbasiert zu data-ps-*. Jedes querySelector('.something') gegen das PrestaShop-eigene DOM kann plötzlich nichts mehr finden.

Die Pre-Upgrade-Checkliste, die wir in Kundenshops verwenden

Inventarisieren Sie jedes installierte Modul mit Anbieter und Version
Prüfen Sie jedes Anbieter-Changelog auf einen ausdrücklichen 9.0/9.1-Eintrag nach dem PS-9-Release
Aktualisieren Sie jedes Modul auf die neueste Version, bevor Sie PrestaShop selbst upgraden
Stellen Sie eine Staging-Umgebung mit einer frischen Kopie der Produktionsdatenbank bereit
Installieren Sie PS 9.1 im Staging, direkt auf 9.1, nicht über 9.0
Installieren Sie Module in Abhängigkeitsreihenfolge und beobachten Sie nach jedem Schritt die Logs
Führen Sie die tatsächliche Funktion jedes Moduls aus, Bestellungen, Importe, Exporte, Sitemaps, E-Mails
Rendern Sie das Frontend mit dem Theme, das Sie in Produktion nutzen werden
Geben Sie eine vollständige echte Testbestellung über die Kasse auf, einschließlich Zahlungsbestätigung
Lesen Sie das PHP-Fehlerlog auf Deprecation-Warnungen. Sie sind künftige Fatals
Prüfen Sie bei jedem Modul, das E-Mails sendet, ob diese E-Mails tatsächlich gesendet wurden
Erstellen Sie ein vollständiges Backup (Datenbank, Dateien, Konfiguration) und bewahren Sie es mindestens 30 Tage nach dem Upgrade auf
Planen Sie das Live-Upgrade für das verkehrsärmste Zeitfenster Ihres Shops
Halten Sie das 8.x-Backup mindestens einen Monat bereit. Ein Rollback sollte möglich bleiben, bis Sie sicher sind

Fazit

PS 9 ist eine echte Verbesserung, sobald man darauf läuft. Symfony 6.4 ist tatsächlich schneller, Hummingbird ist wirklich schlanker als Classic, und die AdminAPI eröffnet Integrationsmuster, die der alte Webservice nicht erreicht. Nichts davon hilft Ihnen, wenn das Upgrade die Module bricht, auf denen Ihr Shop läuft.

Die Migration ist machbar. Sie ist kein Wochenendjob, und „kompatibel“ ist ein Wort, das Anbieter mit konkreten Nachweisen unterfüttern sollten. Wir haben die Arbeit über unseren Katalog hinweg erledigt, auf unserer eigenen Infrastruktur, gegen genau die PrestaShop-Versionen, die wir nennen, weil jeder Shop, der unsere Module nutzt, irgendwann upgradet, und wir die Arbeit lieber einmal sauber machen, als endlos Support-Tickets zu beantworten.

Wenn Sie Module wollen, bei denen die PS-9-Arbeit bereits erledigt ist (dasselbe ZIP, alle PS-Versionen, keine Upgrade-Gebühr), starten Sie mit dem mypresta.rocks-Katalog. Wenn Sie Unterstützung bei der Bewertung Ihres bestehenden Stacks möchten, schreiben Sie uns.

Häufig gestellte Fragen

Was ist der Unterschied zwischen „installiert auf PS 9“ und „kompatibel mit PS 9“?
Eine Installation beweist fast nichts. Auf PS 9 kann ein Modul sauber installieren, seine Konfigurationsseite rendern und trotzdem still kaputt sein, weil die benötigte Bibliothek (Guzzle, SwiftMailer, Tactician) nicht mehr im Core liegt und erst dann fatal abbricht, wenn der relevante Codepfad läuft, oder weil es sich auf einen von PS 9 entfernten Hook registriert hat und die Funktion einfach nie feuert. „Kompatibel“ sollte heißen, dass das Modul seine echte Aufgabe Ende zu Ende erfüllt hat, eine aufgegebene Bestellung, eine gesendete E-Mail, eine generierte Sitemap, auf der Version, für die die Aussage gilt, und nicht nur, dass der Installer keinen Fehler geworfen hat.

Sollte ich einem „PrestaShop-9-kompatibel“-Badge auf der Startseite eines Anbieters vertrauen?
Nicht für sich allein. Suchen Sie nach einem Changelog-Eintrag nach dem Release von PrestaShop 9, der konkrete Arbeiten an 9.x erwähnt, Symfony-6.4-Controller, Tests mit PHP 8.1+, Ersatz entfernter Hooks. Wenn das jüngste Update von 2023 stammt und der Marketingtext immer noch mit „1.7-kompatibel“ führt, ist das Modul wahrscheinlich verlassen und die Website hat nur noch nicht aufgeholt. Die beste einzelne Frage an einen Entwickler ist, ob er von FrameworkBundleAdminController wegmigriert ist; wenn er es nicht erkennt, haben Sie etwas gelernt.

Warum speziell auf 9.1 testen und nicht nur auf 9.0?
Weil 9.1 zusätzlich zu 9.0 eigene Breaking Changes eingeführt hat, Bootstrap 5.3.3, den aus Hummingbird entfernten Hook displaySearch, Theme::getDefaultTheme(), das „classic“ nicht mehr fest kodiert, und die Bewegung hin zu data-ps-*-Selektoren. Ein Modul, das nur auf 9.0 geprüft wurde, ist für die Version, die Händler tatsächlich installieren, nur halb getestet. Gehen Sie im Staging direkt auf 9.1 statt über 9.0.

Eines meiner Module sendet E-Mails und funktioniert nach dem Upgrade nicht mehr. Warum?
Mit hoher Wahrscheinlichkeit, weil es SwiftMailer direkt aufgerufen hat, den PS 9 nicht mehr mitliefert. Die Korrektur ist ein Anbieter-Update auf Symfony Mailer. Es gibt keinen zuverlässigen clientseitigen Workaround. Zwei verwandte Fallen: reine SSL-SMTP-Verschlüsselung ist in PS 9 weg (nur TLS oder keine Verschlüsselung bleiben), sodass ein für SSL konfiguriertes Relay still stoppt; und ein Modul, das über PrestaShops eigenes Mail::Send() geht, statt Swift selbst zu instanziieren, ist dasjenige, das weiter funktioniert.

Brauche ich eine separate „PrestaShop-9-Edition“ eines Moduls?
Sollten Sie nicht. Ein gut gebautes Modul wird als einzelnes ZIP ausgeliefert, das zur Laufzeit auf _PS_VERSION_ verzweigt, sodass derselbe Download auf 1.7.6+, 8.x und 9.x installiert. Wenn ein Anbieter Ihnen einen separaten PS-9-Build gibt, ist das in jedem Shop mit mehreren PrestaShop-Versionen eine Wartungsfalle, und es signalisiert meist, dass die Kompatibilität nachträglich angebaut statt von Anfang an sauber vorgesehen wurde.