Jedes Modul, das wir ausliefern, läuft auf PrestaShop 9. Das war der Aufwand dahinter.
Wir haben Anfang 2024 begonnen, unseren Katalog gegen PrestaShop-9-Alphas neu zu prüfen. Als 9.0 stable erschien, lief unsere interne CI bereits jedes Modul-ZIP durch sieben PrestaShop-Versionen und vier PHP-Versionen, bevor wir eine Zeile mergen. Heute installiert und läuft jedes Modul aus unserem Katalog mit 140+ Modulen auf PS 9.0 und 9.1 aus demselben ZIP, das auch auf 8.x und 1.7.6+ läuft. Eine Codebasis, Runtime-Versionserkennung, keine „PrestaShop 9 Edition“-Preise.
Das ist die Überschrift. Der Rest dieses Beitrags ist der Teil, den die meisten „wir unterstützen PS 9!“-Ankündigungen auslassen: was bei der Migration wirklich gebrochen ist, was wir nur durch Tests auf echten Shops gefunden haben und welche Fragen Sie anderen Anbietern stellen sollten, bevor Sie einer Kompatibilitätsaussage vertrauen.
Was PrestaShop 9 wirklich geändert hat
Wer nur die PrestaShop-Zusammenfassung gelesen hat, könnte PS 9 für ein ordentliches Symfony-Upgrade halten. Das ist es nicht. Es ist das disruptivste Release seit 1.7 Symfony eingeführt hat, und die Brüche liegen genau in den Bereichen, die Module am häufigsten berühren.
Symfony 4.4 zu 6.4 — zwei Majors auf einmal
Hier fallen viele Drittmodule um. In 4.4 konnte man in einem Admin-Controller $this->get('service_name') schreiben und etwas aus dem Container ziehen. In 6.4 funktioniert das noch über eine Kompatibilitätsschicht, aber die Basisklasse FrameworkBundleAdminController ist offiziell deprecated und für PrestaShop 10 zur Entfernung vorgesehen.
Übersetzung: Wenn ein Modul heute auf PS 9 rendert, aber weiterhin FrameworkBundleAdminController erweitert, hat es ein bekanntes Ablaufdatum. Wir haben alle Admin-Controller auf PrestaShopAdminController mit sauberer Constructor Injection umgebaut. Das ist der langsamste Teil der Migration und 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 Core-vendor/ bekamen:
- Guzzle — ersetzt durch Symfony HTTP Client. Ein Modul mit
use GuzzleHttp\Client, das keine eigene Kopie ausliefert, endet beim ersten HTTP-Call mit einem Class-not-found-Fatal. - SwiftMailer — ersetzt durch Symfony Mailer. Module, die direkt über Swift senden, bekommen nicht nur eine Deprecation, sondern einen Fatal.
- Tactician command bus — ersetzt durch Symfony Messenger. CQRS-Code über Tactician muss umgeschrieben werden.
Das Tückische: Diese Fehler zeigen sich nicht bei der Installation. Das Modul lädt, die Konfiguration rendert, und es crasht erst, wenn ein Cron läuft oder ein Kunde den Mailpfad auslöst. Genau so haben wir in Alpha-Tests zwei eigene Module gefunden.
33 Hooks entfernt
Das ist kein Tippfehler und keine Deprecation — sie sind weg. Die Entfernungen gruppieren sich so:
- Legacy-Admin-Produkt-Hooks — der alte Produkteditor ist verschwunden und nahm seine Hooks mit (
actionAdminProductsControllerXxx,actionAdminActivateAfter/Before,actionAdminDeactivateAfter/Before,actionAdminDeleteAfter/Before,actionAdminSortAfter/Before) - Admin-Login-Hooks — jetzt über Symfony Security (
actionAdminLoginControllerBefore,actionAdminLoginControllerLogin/Forgot/Reset Before/After) - AdminController-Lifecycle-Hooks —
initHeader,initContent,initFooter,displayfeuern noch auf Legacy-Controllern imLegacyController, neue Symfony-Adminseiten überspringen sie. Testen Sie jede Adminseite, auf der Ihr Modul erscheint.
In der Praxis ist das schlimmer als ein Crash: Das Modul registriert einen entfernten Hook, die Installation klappt, der Hook feuert nie, und die Funktion ist still tot.
PHP 8.1 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 eigene Deprecations hat. Was in 8.3 nur Logs füllt, ist in 8.4 oft ein harter Fehler.
Advanced Stock Management ist weg
Das gesamte Subsystem (Lieferantenbestellungen, Lager, ASM-Adminoberfläche) wurde in PS 9 entfernt. Auch die Tabellen sind weg. Module, die direkt ps_supply_order* oder ps_warehouse* abfragen, werfen SQL-Fehler. Zwei unserer Module (mprwarehouserevolution und mprstockorder) verwalten Lagerdaten unabhängig von ASM, weil wir nie darauf vertraut haben, dass ASM überlebt — diese Wette hat sich ausgezahlt.
Context singleton wird zurückgefahren
PS 9 führt dedizierte Context-Services ein: EmployeeContext, ShopContext, CurrencyContext, CountryContext, LanguageContext. Context::getContext() funktioniert noch, riecht aber inzwischen nach Altcode. Wir migrieren es opportunistisch, wenn wir ohnehin in einer Datei arbeiten.
trans() escaped HTML nicht mehr
Das ist gefährlich, weil es unsichtbar ist. In PS 8 und älter escaped trans() HTML-Entities als Nebeneffekt. Viel Modulcode verließ sich versehentlich darauf als XSS-Schutz. In PS 9 müssen dynamische Inhalte vor trans() explizit mit htmlspecialchars() behandelt werden.
Hummingbird, Bootstrap 5 und die jQuery-Uhr
PS 9.1 liefert Hummingbird als Default-Theme für neue Installationen, auf Bootstrap 5.3.3. Für Frontend-Module heißt das:
- Bootstrap-4-Utilities sind weg (
.no-gutterswird.g-0,.custom-checkboxwird.form-check) - Data-Attribute sind namespaced (
data-togglewirddata-bs-toggle) - jQuery ist in Hummingbird offiziell deprecated und läuft auf Entfernung zu. Unsere Frontend-JS für checkout, performance und product tabs ist bereits Vanilla.
- PrestaShop-spezifische Klassenselektoren werden durch
data-ps-*-Attribute ersetzt — wer.cart-blocktargetet, muss umstellen.
Wie Sie Ihren bestehenden Modul-Stack prüfen
Die meisten Shops laufen nicht nur mit unseren Modulen. Sie haben fünfzehn bis vierzig Module von vielen Anbietern. Das ist der Prozess, den wir bei Migrationen nutzen.
Step 1: Ehrliches Inventar
Module → Module Manager. Liste exportieren. Für jedes Modul: Name, Version, Anbieter, letztes Update, Kritikalität. Ein Payment Gateway ist kritisch; ein Social-Share-Widget ist Dekoration.
Step 2: Changelog lesen, nicht die Headline
„PrestaShop 9 compatible“ auf einer Homepage bedeutet wenig. Sie wollen einen Changelog-Eintrag nach dem öffentlichen PS-9-Release, der Symfony 6.4, PHP 8.1+ Tests oder Hook-Ersatz konkret nennt.
Step 3: Modulcode greppen
Wenn Sie einen Entwickler oder Shell-Zugang haben, entpacken Sie das Modul und suchen Sie nach Mustern mit garantiertem Risiko:
# Legacy-Symfony-4.4-Servicezugriff
grep -rn '\$this->get(' modules/yourmodule/
# Entfernte Core-Bibliotheken
grep -rn 'use GuzzleHttp' modules/yourmodule/
grep -rn 'Swift_\|SwiftMailer' modules/yourmodule/
grep -rn 'League\\Tactician' modules/yourmodule/
# Veraltete Preisformatierung (entfernt in PS 9.0)
grep -rn 'Tools::displayPrice' modules/yourmodule/
# Bootstrap-4-Data-Attribute
grep -rn 'data-toggle=' modules/yourmodule/views/templates/
# jQuery-Nutzung in Frontend-JS
grep -rn '\$.ajax\|\$(document)' modules/yourmodule/views/js/Ein Treffer auf use GuzzleHttp ohne eigenes composer.json mit Guzzle ist ein bestätigter Crash auf PS 9. Tools::displayPrice ist ein harter Fatal. Wir kapseln solche Stellen intern in prestashop-compat.
Step 4: Staging, das Produktion wirklich spiegelt
Testen Sie nie auf dem Live-Shop. Unsere Minimalrezeptur:
- Produktionsdatenbank in eine separate DB klonen
- PS 9.1 darauf installieren — direkt 9.1, nicht über 9.0
- Module in Abhängigkeitsreihenfolge installieren: Payment und Versand zuerst, dann SEO/Marketing, dann Kosmetik
- Nach jeder Installation PHP-Log und PrestaShop-Log unter
var/logs/beobachten. Warnungen nicht ignorieren - Die echte Aufgabe des Moduls testen: Testbestellung, Import, Sitemap, Mail. Eine geöffnete Konfigurationsseite beweist fast nichts
Die wertvollste Gewohnheit:
tail -f var/logs/*in einem Terminal, während man im Backoffice klickt. Deprecation-Lärm ist der Frühindikator für Brüche in der nächsten Version.
Step 5: Frontend-Smoke-Test auf dem Theme, das Sie wirklich nutzen
Bei Hummingbird braucht jedes Frontend-Modul eine visuelle Prüfung im echten Theme. Besonders anfällig sind:
- Checkout — Payment-Formulare, Carrier-Blöcke, Adressvalidierung, Order Summary
- Produktseiten — Reviews, Wunschlisten, Größentabellen, Custom Fields
- Header/Footer — Mega-Menüs und Such-Dropdowns
- Kategoriefilter und Sortierung
Bei Classic ist das Risiko kleiner, aber nicht null, weil Bootstrap 5 im Admin landet und manche Module CSS zwischen Front und Back teilen.
Die Fragen, die Sie einem Anbieter stellen sollten
„Ist Ihr Modul PrestaShop-9-kompatibel?“ liefert fast immer „ja“. Fragen Sie besser:
- Ist das Modul auf 9.0 und 9.1 getestet? 9.1 brachte Bootstrap 5.3.3, entfernte
displaySearchund änderte diedata-ps-*-Konvention. Nur 9.0 zu testen ist halbe Arbeit. - Ist es dasselbe ZIP für 8.x und 9.x? Separate Downloads sind eine Wartungsfalle. Runtime-Versionserkennung ist der saubere Weg.
- Wurde
FrameworkBundleAdminControllerverlassen? Wenn der Entwickler die Frage nicht erkennt, wissen Sie etwas Wichtiges. - Braucht das Frontend-JS noch jQuery? Heute okay, aber fragen Sie nach dem Migrationsplan.
- Wie sieht die PHP-Testmatrix aus? Die gewünschte Antwort ist „8.1 bis 8.4“, nicht „PHP 8“.
Wann upgraden, wann warten
Jetzt gehen, wenn Ihre kritischen Module PS-9.1-Kompatibilität explizit bestätigen, Sie auf PHP 8.1+ sind, eine funktionierende Staging-Kopie haben und Ihr Theme Classic, Hummingbird oder ein Child davon ist.
Drei bis sechs Monate warten, wenn ein oder zwei Nice-to-have-Module noch keine Bestätigung haben, Ihr Theme stark angepasst ist oder Sie Advanced Stock Management noch nicht ersetzt haben.
Nicht upgraden, wenn ein kritisches Modul keine PS-9-Aussage hat, der Anbieter seit einem Jahr nichts ausgeliefert hat, Sie noch auf PHP 7.4/8.0 sind oder Ihr Shop schwere Agentur-Customizations ohne PS-9-Test nutzt.
Wie wir unsere 140+ Module wirklich auf PS 9 gebracht haben
Das ist wichtig, weil „wir unterstützen PrestaShop 9“ je nach Anbieter sehr Unterschiedliches bedeutet.
Phase 1: Statische Analyse über den ganzen Katalog
Ein Scanner suchte in jedem Modul nach Legacy-Controllern, Guzzle/Swift/Tactician, Tools::displayPrice, Bootstrap-4-Markup und jQuery. Ergebnis war eine nach Risiko sortierte Arbeitsliste pro Modul.
Phase 2: Symfony-6.4-Controller-Migration
Jeder Admin-Controller mit Service-Container-Zugriff ging von $this->get() auf Constructor Injection. Jeder deprecated Base Controller wurde zu PrestaShopAdminController. Das ist die langsame Phase.
Phase 3: Hook-Audit und Ersatz
Wir glichen jedes registerHook() gegen die entfernten Hooks ab. Wo ein Hook weg war, migrierten wir zum Ersatz oder registrierten versionsabhängig im Installer.
Phase 4: Gemeinsame Compat-Schicht
Methoden mit Entfernungsrisiko leben hinter Wrappern in prestashop-compat. Tools::displayPrice ist jetzt \MyPrestaRocks\Compat\PriceFormatter::format() in allen 140+ Modulen.
Phase 5: Matrix-Tests in CI
Jedes ZIP läuft durch PrestaShop 1.7.6, 1.7.7, 1.7.8, 8.0, 8.1, 9.0 und 9.1 — jeweils mit PHP 8.1, 8.2, 8.3 und 8.4. Wir nutzen eigene Docker-Container (ps176-dev, ps178-dev, ps8-dev, ps9-dev). Ein ZIP funktioniert überall, weil es zur Laufzeit auf _PS_VERSION_ reagiert.
Phase 6: Hummingbird- und Classic-Prüfung
Jedes Modul mit Frontend-Ausgabe wird vor Release auf beiden Themes gerendert. Wo Templates sich unterscheiden müssen, entscheidet PrestaShops Versionshelper.
Wo wir ehrlich geblieben sind
Module, die Produkt-Tabs, Multi-Shop-Kontext oder AdminAPI-Brücken berühren, wurden auf PS 9.0 und 9.1 manuell end-to-end getestet. Wir behaupten Kompatibilität nicht, weil die Kategorie ungefähr sicher aussieht, sondern weil der Modulpfad auf der Version lief.
Das Ergebnis: Jedes Modul im mypresta.rocks-Katalog installiert und läuft auf PS 9.0 und 9.1 aus demselben ZIP wie auf 8.x und 1.7.6+. Keine Sonderedition, keine Migrationsgebühr.
Was nach einem erfolgreichen Upgrade schiefgeht
Auch mit bestätigten Modulen sehen wir diese Muster:
500-Fehler nach Installation eines einzelnen Moduls
Fast immer fehlt eine Composer-Abhängigkeit im eigenen vendor/ des Moduls. Das PHP-Log nennt „Class not found“, meist GuzzleHttp\Client, Swift_Mailer oder Symfony Messenger. Modul aktualisieren oder vorübergehend die Bibliothek manuell beilegen.
Adminseite lädt, Feature ist still tot
Das entfernte-Hook-Problem. Die Konfiguration rendert, aber der Hook feuert nie. Prüfen Sie install() gegen die PS-9-Liste. Der Fix ist ein Anbieter-Update.
Frontend auf Hummingbird kaputt, auf Classic ok
Bootstrap-4-zu-5-Drift: .no-gutters, .custom-checkbox, data-toggle und ähnliches. Workaround: Classic nutzen. Echter Fix: Template-Update.
JavaScript-Fehler in der Konsole
Entweder wird jQuery erwartet, ist aber nicht geladen, oder Selektoren zielen auf alte Klassen statt data-ps-*. $ is not defined ist das Signal.
E-Mails werden nicht mehr gesendet
Das Modul instanziiert SwiftMailer direkt statt Mail::Send(). PS 9 hat keinen SwiftMailer. Es braucht ein Update auf Symfony Mailer.
PrestaShop 9.1 — die Extras, die Sie kennen müssen
Wenn Sie direkt auf 9.1 gehen, kommen zusätzlich zu 9.0 eigene Brüche:
Theme::getDefaultTheme()hardcodiert „classic“ nicht mehr. Module mit dieser Annahme verhalten sich falsch.- Der Hook
displaySearchist aus Hummingbird entfernt. Suchmodule brauchen einen anderen Hook. - D3 und NVD3 wurden angehoben. Dashboard-Widgets mit spezifischer D3-API können falsch rendern.
- JavaScript-Selektoren wandern von Klassen zu
data-ps-*.querySelector('.something')kann gegen PrestaShops DOM ins Leere laufen.
Unsere Pre-Upgrade-Checkliste für Kundenshops
- Jedes installierte Modul mit Anbieter und Version inventarisieren
- Jedes Anbieter-Changelog auf expliziten 9.0/9.1-Eintrag nach PS-9-Release prüfen
- Alle Module vor dem PrestaShop-Upgrade aktualisieren
- Staging mit frischer Produktionsdatenbank bereitstellen
- PS 9.1 auf Staging installieren — direkt 9.1, nicht über 9.0
- Module in Abhängigkeitsreihenfolge installieren und Logs beobachten
- Jede echte Funktion ausführen — Bestellungen, Importe, Exporte, Sitemaps, E-Mails
- Frontend auf dem Produktionstheme rendern
- Eine vollständige Testbestellung inklusive Zahlungsbestätigung platzieren
- PHP-Log auf Deprecations lesen — sie sind künftige Fatals
- Prüfen, ob jedes mailende Modul wirklich gesendet hat
- Vollbackup für 30+ Tage nach Upgrade halten
- Live-Upgrade in die niedrigste Traffic-Zeit legen
- 8.x-Backup mindestens einen Monat rollback-fähig halten
Closing
PS 9 ist eine echte Verbesserung, sobald Sie darauf sind — Symfony 6.4 ist schneller, Hummingbird leichter als Classic und die AdminAPI öffnet Integrationsmuster, die der Legacy Webservice nicht erreicht. Nichts davon hilft, wenn das Upgrade die Module bricht, auf denen Ihr Shop läuft.
Die Migration ist machbar. Sie ist kein Wochenendjob, und „kompatibel“ sollten Anbieter mit Details belegen. Wir haben diese Arbeit über unseren Katalog hinweg auf eigener Infrastruktur und gegen die PrestaShop-Versionen erledigt, die wir nennen.
Wenn Sie Module wollen, bei denen die PS-9-Arbeit erledigt ist, starten Sie mit dem mypresta.rocks-Katalog. Wenn Sie Hilfe bei der Bewertung Ihres Stacks möchten, melden Sie sich.
Kommentare
Noch keine Kommentare. Seien Sie der Erste!
Stellen Sie als Erster eine Frage oder teilen Sie hilfreiches Feedback.
Kommentar schreiben
Teilen Sie eine Frage, ein Installationsdetail oder Feedback, das anderen Lesern helfen kann.