Migration auf PrestaShop 9: Vollständige Upgrade-Anleitung

Warum Sie auf PrestaShop 9 upgraden sollten

PrestaShop 9 ist die größte architektonische Veränderung seit dem Sprung von 1.6 auf 1.7. Es handelt sich nicht nur um eine Versionserhöhung — es ist eine grundlegende Modernisierung der Plattform. Wenn Sie PrestaShop 1.7 oder 8.x betreiben, lautet die Frage nicht, ob Sie upgraden sollten, sondern wann und wie Sie es richtig machen.

Das bringt PrestaShop 9 mit sich:

Symfony 6.4 LTS unter der Haube

PrestaShop 9 wechselt von Symfony 4.4 (PS 8.x) auf Symfony 6.4 LTS. Dies ist ein Long-Term-Support-Release, das heißt, Sie erhalten Sicherheits-Patches und Bugfixes bis November 2027. Das Symfony-Upgrade bringt moderne Dependency Injection, verbessertes Routing, bessere Fehlerbehandlung und einen deutlich schnelleren Reqüst-Lifecycle.

Für Shop-Betreiber bedeutet das eine stabilere und sicherere Grundlage. Für Entwickler bedeutet es Zugang zu modernen Symfony-Komponenten und -Patterns, die sich im PHP-Ökosystem als Standard etabliert haben.

PHP 8.2+ erforderlich

PrestaShop 9 erfordert mindestens PHP 8.2, mit voller Unterstützung für PHP 8.3. Das ist nicht willkürlich — PHP 8.2+ bringt Readonly-Klassen, Fibers, ein verbessertes Typsystem und spürbare Leistungsverbesserungen. Benchmarks zeigen eine 5–15% schnellere Ausführung im Vergleich zu PHP 7.4, bei geringerem Speicherverbrauch in allen Bereichen.

Wenn Sie noch PHP 7.4 oder 8.0 verwenden, wird allein das Upgrade auf PHP 8.2+ Ihren Shop merklich schneller machen — noch bevor Sie PrestaShop anfassen.

Twig überall im Admin-Bereich

Das Back Office hat seine Migration von Smarty zu Twig abgeschlossen. Jede Admin-Seite läuft jetzt auf Twig-Templates, was schnelleres Rendering, bessere Sicherheit (automatisches Output-Escaping) und eine Template-Engine bedeutet, die tatsächlich gewartet und gut dokumentiert ist. Legacy-Admin-Controller funktionieren weiterhin über eine Kompatibilitätsschicht, aber die Richtung ist klar: Twig ist die Gegenwart und die Zukunft.

Hummingbird als Standard-Theme

Das Classic-Theme wird durch Hummingbird als Standard-Front-Office-Theme ersetzt. Hummingbird basiert auf Bootstrap 5.3, nutzt moderne CSS Custom Properties und ist deutlich leichter als Classic. Es ist auf Performance ausgelegt — kleinere CSS-Bundles, weniger JavaScript und bessere Core Web Vitals-Werte direkt nach der Installation.

Sicherheitsverbesserungen

Symfony 6.4 bringt eine komplett überarbeitete Sicherheitskomponente. Passwort-Hashing nutzt moderne Algorithmen (bcrypt/argon2), der CSRF-Schutz ist robuster, und das Authentifizierungssystem basiert auf dem Symfony Security Bundle statt auf dem veralteten Cookie-basierten Ansatz von PrestaShop. SQL-Injection- und XSS-Schwachstellen in Legacy-Code-Pfaden wurden systematisch beseitigt.

PrestaShop 9 ist kein kosmetisches Update. Es verändert, wie die Plattform im Kern funktioniert. Genau deshalb müssen Sie das Upgrade methodisch angehen — die Belohnung ist ein schnellerer, sichererer und besser wartbarer Shop, aber nur, wenn Sie die Migration korrekt durchführen.

Bevor Sie beginnen: Checkliste der Voraussetzungen

Fassen Sie Ihren Live-Shop nicht an, bevor Sie jeden Punkt auf dieser Liste überprüft haben. Das Überspringen von Voraussetzungen ist die häufigste Ursache für fehlgeschlagene Upgrades.

Server-Anforderungen

• PHP 8.2 oder 8.3 — prüfen Sie mit php -v auf Ihrem Server. PHP 8.1 funktioniert NICHT.
• MySQL 8.0+ oder MariaDB 10.4+ — prüfen Sie mit mysql --version. MySQL 5.7 wird nicht mehr unterstützt.
• Erforderliche PHP-Erweiterungen: intl, gd, curl, zip, mbstring, openssl, pdo_mysql, fileinfo, dom, json
• Composer 2.x — wird für das Dependency-Management während des Upgrades benötigt
• Mindestens 256MB PHP memory_limit — der Upgrade-Prozess ist speicherintensiv
• max_execution_time von mindestens 600 Sekunden — große Shops benötigen Zeit für Datenbank-Migrationen

So überprüfen Sie Ihr PHP-Setup schnell:

# Check PHP version
php -v

# Check loaded extensions
php -m | grep -E "(intl|gd|curl|zip|mbstring|openssl|pdo_mysql)"

# Check memory limit and execution time
php -i | grep -E "(memory_limit|max_execution_time)"

# Check MySQL version
mysql --version

PrestaShop-Versionsanforderungen

• Sie müssen zuerst auf PrestaShop 8.1 oder 8.2 sein. Direkte Upgrades von 1.7.x oder 1.6.x auf 9.x werden nicht unterstützt.
• Wenn Sie PS 1.7.x verwenden, upgraden Sie zuerst auf 8.2, stabilisieren Sie, und upgraden Sie dann auf 9.x.
• Wenn Sie PS 1.6.x verwenden — stoppen Sie. Sie brauchen einen kompletten Neuaufbau, kein Upgrade. Siehe den Abschnitt „Neuinstallation“ weiter unten.

Modul-Kompatibilitätsprüfung

Hier scheitern die meisten Upgrades. Bevor Sie upgraden, müssen Sie wissen, welche Ihrer Module PS9-kompatibel sind und welche nicht.

1. Erstellen Sie eine vollständige Liste aller installierten Module (Back Office → Module → Modulmanager)
2. Kontaktieren Sie für jedes Drittanbieter-Modul den Anbieter und fragen Sie: „Ist Version X.Y kompatibel mit PrestaShop 9?“
3. Für jedes Modul, das nicht als kompatibel bestätigt ist, brauchen Sie einen Plan: upgraden, ersetzen oder entfernen
4. Achten Sie besonders auf Zahlungsmodule — ein inkompatibles Zahlungs-Gateway bedeutet null Umsatz

Gehen Sie nicht davon aus, dass ein Modul kompatibel ist, weil es „unter PS 8 funktioniert hat.“ PrestaShop 9 entfernt APIs und ändert das Kernverhalten. Ein Modul, das unter 8.2 einwandfrei lief, kann unter 9.0 abstürzen, weil es eine Funktion aufruft, die nicht mehr existiert.

Theme-Kompatibilität

• Wenn Sie das Standard-Classic-Theme verwenden, müssen Sie zu Hummingbird oder einem PS9-kompatiblen Drittanbieter-Theme wechseln
• Wenn Sie ein gekauftes Theme verwenden, überprüfen Sie die PS9-Kompatibilität beim Theme-Entwickler
• Auf Classic basierende benutzerdefinierte Themes erfordern erhebliche Überarbeitung — die Template-Struktur hat sich geändert
• Hummingbird-Child-Themes sind der empfohlene Weg nach vorn

Geschäftliches Timing

• Upgraden Sie niemals während Spitzenverkaufszeiten (Black Friday, Weihnachten, große Aktionen)
• Planen Sie das Upgrade für Ihre verkehrsärmste Zeit — typischerweise unter der Woche, früh morgens
• Planen Sie mindestens 48 Stunden Überwachungszeit nach dem Upgrade ein, bevor Ihr nächster Spitzenzeitraum beginnt
• Halten Sie einen Rollback-Plan bereit (wird weiter unten behandelt)

Sichern Sie zuerst alles

Das ist nicht optional. Das ist nicht „empfohlen.“ Das ist der wichtigste einzelne Schritt. Wenn Ihr Upgrade fehlschlägt und Sie kein Backup haben, verlieren Sie Ihren Shop. Punkt.

Datenbank-Backup

Die Datenbank enthält alles, was zählt — Produkte, Kunden, Bestellungen, Konfigurationen, Modul-Einstellungen. Sichern Sie sie mit mysqldump:

# Standard mysqldump � works on any server
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

# If your database is large (>1GB), add compression
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop | gzip > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql.gz

Wenn Ihr PrestaShop in Docker läuft:

# Replace 'my-shop-db' with your actual database container name
docker exec my-shop-db mysqldump -u root -p'YOUR_PASSWORD' --single-transaction --quick prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

Erklärung der Flags:

• --single-transaction — erstellt einen konsistenten Snapshot, ohne Tabellen zu sperren (wichtig für InnoDB)
• --quick — ruft Zeilen einzeln ab, statt sie im Speicher zu puffern (essentiell für große Tabellen)
• --lock-tables=false — vermeidet das Sperren von Tabellen während des Dumps, damit Ihr Shop online bleibt

Überprüfen Sie, ob Ihr Backup funktioniert, indem Sie es in eine Testdatenbank importieren:

# Create a test database and import the backup
mysql -u root -p -e "CREATE DATABASE prestashop_backup_test;"
mysql -u root -p prestashop_backup_test < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# Check that it imported correctly
mysql -u root -p prestashop_backup_test -e "SELECT COUNT(*) FROM ps_product; SELECT COUNT(*) FROM ps_orders;"

# Clean up
mysql -u root -p -e "DROP DATABASE prestashop_backup_test;"

Datei-Backup

Sichern Sie das gesamte PrestaShop-Verzeichnis — alle PHP-Dateien, Themes, Module, hochgeladene Bilder, alles:

# Full file backup with tar
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /var/www/html/

# If you want to exclude cache and logs (they're regenerated anyway)
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz \
  --exclude='var/cache' \
  --exclude='var/logs' \
  /var/www/html/

Für Docker-basierte Shops sichern Sie das gemountete Volume:

tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /path/to/docker/html/

Speichern Sie Ihre Backups an mindestens zwei Orten — auf dem Server selbst UND an einem externen Speicherort (Ihr lokaler Rechner, ein Cloud-Speicher oder ein anderer Server). Ein Backup, das nur auf derselben Festplatte wie Ihr Shop existiert, ist kein echtes Backup.

Konfigurationsnotizen

Dokumentieren Sie vor dem Start diese Einstellungen (Sie werden sie brauchen, falls Sie neu konfigurieren müssen):

• Ihre app/config/parameters.php (Datenbank-Zugangsdaten, Mailer-Konfiguration, Cookie-Schlüssel)
• Ihre .htaccess-Datei (besonders wenn Sie benutzerdefinierte Rewrite-Regeln hinzugefügt haben)
• SMTP-/E-Mail-Konfiguration aus dem Back Office
• API-Schlüssel und Einstellungen der Zahlungs-Gateways
• Cron-Job-Konfigurationen
• Alle benutzerdefinierten Server-Konfigurationen (Nginx-Regeln, PHP-FPM-Pool-Einstellungen)

Machen Sie Screenshots von kritischen Back-Office-Einstellungsseiten. Wenn während des Upgrades etwas schiefgeht, ist eine visuelle Referenz von „wie es vorher aussah“ von unschätzbarem Wert.

Schritt-für-Schritt-Upgrade-Prozess

Es gibt zwei seriöse Wege zu PrestaShop 9: das In-Place-Upgrade mit dem offiziellen Modul oder eine Neuinstallation mit Datenmigration. Beide haben ihren Platz.

Ansatz 1: Auto-Upgrade-Modul (1-Click Upgrade)

Der offizielle Upgrade-Pfad nutzt das autoupgrade-Modul (auch „1-Click Upgrade“ genannt). Dieses Modul übernimmt den Dateiaustausch, die Datenbank-Migration und die Aufräumarbeiten nach dem Upgrade automatisch.

Vorbereitung

1. Installieren oder aktualisieren Sie das 1-Click Upgrade-Modul auf die neüste Version aus dem PrestaShop Marketplace
2. Gehen Sie zu Back Office → Module → 1-Click Upgrade
3. Das Modul zeigt Ihre aktuelle Version und verfügbare Upgrade-Ziele an
4. Führen Sie die Pre-Upgrade-Checkliste aus — das Modul prüft die Serverkompatibilität und kennzeichnet potenzielle Probleme

Wartungsmodus aktivieren

# Or do it from the back office: Shop Parameters ? General ? Maintenance ? Enable
# Make sure to whitelist your own IP address

Das ist unbedingt erforderlich. Sie möchten nicht, dass Kunden Bestellungen aufgeben, während die Datenbank migriert wird.

Das Upgrade durchführen

1. Wählen Sie im 1-Click Upgrade-Modul Ihre Zielversion (PrestaShop 9.x)
2. Wählen Sie „Major upgrade“ als Upgrade-Kanal
3. Überprüfen Sie die Upgrade-Optionen:
   • Dateien und Datenbank sichern — aktivieren Sie dies (doppelte Sicherheit, selbst wenn Sie bereits manuell gesichert haben)
   • Nicht-native Module deaktivieren — aktivieren Sie dies, um Modulkonflikte während des Upgrades zu vermeiden
   • E-Mail-Vorlagen neu generieren — aktivieren, wenn Sie sie nicht angepasst haben
4. Klicken Sie auf „Upgrade PrestaShop now“
5. Schließen Sie den Browser-Tab NICHT, navigieren Sie NICHT weg — warten Sie, bis der Prozess abgeschlossen ist

Das Upgrade kann zwischen 5 Minuten (kleiner Shop) und über 30 Minuten (großer Katalog, viele Module) dauern. Sie sehen ein Fortschrittsprotokoll, das jeden Schritt anzeigt.

Nachdem das Upgrade abgeschlossen ist

# Clear all caches � this is not optional
rm -rf var/cache/*

# If using CLI (recommended):
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

# Fix file permissions
chown -R www-data:www-data /var/www/html/var/
chown -R www-data:www-data /var/www/html/themes/
chmod -R 755 /var/www/html/var/

Module einzeln wieder aktivieren

Wenn Sie sich entschieden haben, nicht-native Module während des Upgrades zu deaktivieren, aktivieren Sie nicht alle auf einmal. Aktivieren Sie sie nacheinander:

1. Aktivieren Sie das Modul
2. Prüfen Sie das Front Office und Back Office auf Fehler
3. Wenn es funktioniert, gehen Sie zum nächsten Modul
4. Wenn es etwas kaputt macht, deaktivieren Sie es und kontaktieren Sie den Modul-Anbieter

Dieser methodische Ansatz zeigt Ihnen genau, welches Modul ein Problem verursacht hat, anstatt vor einem defekten Shop mit 30 aktivierten Modulen zu sitzen und keine Ahnung zu haben, welches der Übeltäter ist.

Ansatz 2: Neuinstallation + Datenmigration

Manchmal ist der sauberste Weg nach vorn, von Grund auf neu zu beginnen. Installieren Sie PrestaShop 9 frisch und migrieren Sie Ihre Daten hinein. Dieser Ansatz ist mehr Arbeit, gibt Ihnen aber eine makellose Installation ohne Altlasten.

Wann Sie eine Neuinstallation wählen sollten

• Sie upgraden von PS 1.6.x (In-Place-Upgrade wird für so große Sprünge nicht unterstützt)
• Ihr aktueller Shop hat jahrelang angesammelte Overrides, Hacks und verwaiste Modul-Tabellen
• Sie möchten ohnehin das Theme wechseln
• Ihre Datenbank ist mit verwaisten Warenkörben, alten Logs und verwaisten Daten aufgebläht
• Frühere Upgrade-Versuche sind fehlgeschlagen

Der Prozess

1. Installieren Sie PrestaShop 9 frisch in einem neuen Verzeichnis oder auf einem neuen Server
2. Richten Sie Ihr Theme ein (Hummingbird oder ein PS9-kompatibles Theme)
3. Installieren Sie Ihre Module (nur PS9-kompatible Versionen)
4. Migrieren Sie Ihre Daten mit einer der folgenden Methoden:
   • PrestaShops CSV-Import für Produkte, Kategorien und Kunden
   • Direkte Datenbank-Migration mit benutzerdefinierten SQL-Skripten
   • Drittanbieter-Migrationstools
5. Konfigurieren Sie Zahlungs-Gateways, Versand, Steuern und E-Mail neu
6. Testen Sie alles auf der neuen Installation
7. Wechseln Sie den DNS oder tauschen Sie das Document Root, wenn Sie bereit sind

Datenmigration über CSV-Import

PrestaShops eingebautes Import-Tool (Back Office → Erweiterte Einstellungen → Import) verarbeitet:

• Kategorien
• Produkte (mit Kombinationen, Bildern, Merkmalen und Lagerbestand)
• Kunden
• Adressen
• Hersteller und Lieferanten

Exportieren Sie aus Ihrem alten Shop, bereinigen Sie die CSV-Dateien und importieren Sie in den neuen. Das ist mühsam bei großen Katalogen, liefert aber das sauberste Ergebnis.

Datenmigration über SQL

Für erfahrene Entwickler ist die direkte SQL-Migration bei großen Datenmengen schneller:

# Export specific tables from old database
mysqldump -u root -p old_prestashop \
  ps_product ps_product_lang ps_product_shop \
  ps_category ps_category_lang ps_category_shop \
  ps_customer ps_address \
  ps_image ps_image_lang ps_image_shop \
  ps_stock_available \
  > ~/migration_data.sql

# You'll need to review and adjust the SQL for schema changes between versions
# Column names, table structures, and foreign keys may differ

Die SQL-Migration erfordert tiefgehende Kenntnisse des PrestaShop-Datenbankschemas. Wenn Sie sich nicht sicher im Schreiben und Debuggen komplexer SQL-Abfragen fühlen, verwenden Sie die CSV-Import-Methode oder beauftragen Sie einen Entwickler. Eine misslungene SQL-Migration kann Ihre Daten auf eine Weise beschädigen, die extrem schwer zu beheben ist.

Welcher Ansatz ist besser?

Für die meisten Shop-Betreiber, die PS 8.x mit einer überschaubaren Anzahl gut gewarteter Module betreiben, ist das Auto-Upgrade die richtige Wahl. Eine Neuinstallation ist sinnvoll, wenn Sie von einer sehr alten Version kommen oder die Gelegenheit nutzen möchten, gründlich aufzuräumen.

Modul-Kompatibilität: Was in PrestaShop 9 nicht mehr funktioniert

Dieser Abschnitt richtet sich an Entwickler und technisch interessierte Shop-Betreiber. Das Verständnis der Änderungen hilft Ihnen einzuschätzen, ob Ihre Module das Upgrade überstehen werden.

Smarty-Templates aus dem Admin-Bereich entfernt

Das ist die größte Breaking Change. In PS 8.x konnten Legacy-Admin-Controller noch Smarty-Templates (.tpl-Dateien) für ihre Back-Office-Seiten verwenden. In PS 9 basiert der Admin-Bereich vollständig auf Twig. Legacy-Controller werden von einem Symfony-LegacyController umschlossen, der ihre Ausgabe durch Twig rendert.

Was das in der Praxis bedeutet:

• Module mit benutzerdefinierten Admin-Seiten, die AdminController + Smarty verwenden, funktionieren weiterhin, werden aber über eine Kompatibilitätsschicht im neuen Twig-Layout gerendert
• Admin-Template-Overrides (Dateien in override/controllers/admin/templates/) funktionieren möglicherweise nicht wie erwartet
• In initContent() zugewiesene Smarty-Variablen können verloren gehen, weil LegacyController das Rendering anders umschließt — die Smarty-Variable content muss explizit neu zugewiesen werden
• Die display()-Methode von AdminController wird von PS 9 nicht mehr aufgerufen — LegacyController umgeht sie vollständig

Änderungen am Override-System

PrestaShop rät seit PS 1.7 von Overrides ab, und PS 9 verschärft die Einschränkungen weiter:

• Core-Class-Overrides funktionieren technisch noch, werden aber zunehmend fragil, da immer mehr Kerncode zu Symfony-Services migriert wird
• Controller-Overrides sind unzuverlässig — die Symfony-Routing-Schicht lädt sie möglicherweise nicht wie erwartet
• Template-Overrides in override/-Verzeichnissen sind für Admin-Seiten veraltet
• Der empfohlene Ansatz sind jetzt Hooks, Symfony-Decorators und Event-Subscribers

Wenn Sie Module haben, die stark auf Overrides angewiesen sind, werden diese am wahrscheinlichsten beim Upgrade Probleme bereiten. Überprüfen Sie das override/-Verzeichnis in jedem Modul-Ordner.

Hook-Änderungen

PrestaShop 9 fügt neue Hooks hinzu und ändert einige bestehende:

• Mehrere Legacy-Hooks im Admin-Bereich wurden entfernt oder umbenannt
• Neue Hooks sind für Symfony-basierte Admin-Seiten verfügbar
• Front-Office-Hooks bleiben weitgehend kompatibel (Hummingbird nutzt dieselben Hook-Punkte wie Classic)
• Die Hook-Ausführungsreihenfolge kann sich in einigen Fällen ändern — wenn Ihr Modul davon abhängt, vor oder nach einem anderen Hook aufgerufen zu werden, testen Sie dies

Veraltete Legacy-Controller

Mehrere Admin-Controller-Patterns, die in PS 8.x funktionierten, verhalten sich in PS 9 anders:

• $this->l() (die Übersetzungsfunktion) wurde aus Admin-Controllern entfernt — verwenden Sie stattdessen $this->module->l('string', 'ControllerClassName')
• Tools::displayPrice() wurde entfernt — verwenden Sie Context::getContext()->getCurrentLocale()->formatPrice($amount, $currencyIsoCode)
• Die Admin-Controller-Eigenschaften $this->meta_title, $this->fields_list und $this->bulk_actions müssen NACH dem Aufruf von parent::__construct() zugewiesen werden, da die Modul-Referenz vorher nicht verfügbar ist
• Das Admin-Verzeichnis ist jetzt standardmäßig backoffice/ (nicht admin-dev oder eine zufällige Zeichenkette) — hartcodierte Admin-Pfade werden nicht mehr funktionieren

So prüfen Sie, ob Ihre Module PS9-bereit sind

Für jedes installierte Modul:

1. Überprüfen Sie die Website des Anbieters — suchen Sie nach expliziten PS 9-Kompatibilitätsaussagen
2. Prüfen Sie auf Overrides — schauen Sie in modules/yourmodule/override/. Alle Dateien dort sind ein Warnsignal.
3. Prüfen Sie auf Aufrufe veralteter Funktionen — durchsuchen Sie die PHP-Dateien des Moduls nach:
   • Tools::displayPrice(
   • $this->l( in Admin-Controller-Dateien
   • AdminController-Klassen mit komplexen display()-Methoden
   • Hartcodierten Admin-Verzeichnispfaden
4. Überprüfen Sie die config.xml oder Haupt-PHP-Datei des Moduls auf die ps_versions_compliancy-Einstellung — enthält sie 9.x?

# Quick command to find potential PS9 issues in a module
# Run this from inside the module directory

# Check for overrides
find override/ -type f 2>/dev/null && echo "WARNING: Module uses overrides"

# Check for removed functions
grep -rn "Tools::displayPrice" *.php controllers/ classes/ 2>/dev/null
grep -rn '$this->l(' controllers/admin/ 2>/dev/null

# Check version compatibility declaration
grep -A2 "ps_versions_compliancy" *.php

Theme-Migration: Hummingbird ist jetzt Standard

PrestaShop 9 wird mit Hummingbird als Standard-Theme ausgeliefert und ersetzt damit Classic. Wenn Sie Classic oder ein auf Classic basierendes Theme verwenden, brauchen Sie einen Migrationsplan.

Was sich bei Hummingbird geändert hat

• Bootstrap 5.3 ersetzt Bootstrap 4 — Klassennamen, Grid-System und Utility-Klassen haben sich geändert
• CSS Custom Properties werden intensiv für das Theming genutzt — Farben, Abstände und Typografie werden über CSS-Variablen statt über SCSS-Variablen konfiguriert
• Weniger JavaScript — Hummingbird setzt stärker auf native Browser-Funktionen und weniger auf jQuery-Plugins
• Modernes Build-System — Webpack-basierte Asset-Kompilierung mit echtem Tree Shaking
• Responsive-First-Design — das mobile Layout ist die Basis, Desktop die Erweiterung (im Gegensatz zu Classic, das Desktop-First war)

Wenn Sie das Classic-Theme verwenden

Das Classic-Theme ist in PS 9 nicht enthalten. Ihre Optionen sind:

1. Zu Hummingbird wechseln — der einfachste Weg. Erstellen Sie ein Child-Theme für Ihre Anpassungen.
2. Ein PS9-kompatibles Theme kaufen — viele Theme-Anbieter haben PS9-Versionen veröffentlicht.
3. Ihre Classic-Anpassungen in ein Hummingbird-Child-Theme portieren — das erfordert Frontend-Entwicklungsarbeit, liefert aber das beste Langzeitergebnis.

Ein Hummingbird-Child-Theme erstellen

Ein Child-Theme ermöglicht es Ihnen, Hummingbird anzupassen, ohne Core-Theme-Dateien zu ändern (damit Ihre Änderungen Theme-Updates überstehen):

# Create child theme directory structure
mkdir -p themes/my-child-theme/assets/css
mkdir -p themes/my-child-theme/templates

Erstellen Sie themes/my-child-theme/config/theme.yml:

parent: hummingbird
name: my-child-theme
display_name: My Custom Theme
version: 1.0.0
author:
  name: Your Name

Fügen Sie Ihre benutzerdefinierten Styles in themes/my-child-theme/assets/css/custom.css hinzu. Hummingbird lädt automatisch die custom.css aus Child-Themes mit der niedrigsten Priorität (wird zuletzt geladen), sodass Ihre Styles das Eltern-Theme überschreiben.

Um ein bestimmtes Template zu überschreiben, kopieren Sie es von themes/hummingbird/templates/ in den gleichen relativen Pfad in Ihrem Child-Theme. Kopieren Sie nur die Dateien, die Sie ändern müssen — alles andere fällt automatisch auf das Eltern-Theme zurück.

Wenn Sie ein gekauftes Theme verwenden

Kontaktieren Sie Ihren Theme-Anbieter und stellen Sie diese konkreten Fragen:

• Gibt es eine PS9-kompatible Version?
• Basiert sie auf Hummingbird oder ist es ein eigenständiges Theme?
• Deckt meine bestehende Theme-Lizenz die PS9-Version ab?
• Was ist der Migrationspfad von der aktuellen Version?

Wenn der Anbieter keine PS9-Version hat und Ihnen keinen Zeitplan nennen kann, beginnen Sie jetzt mit der Planung Ihres Wechsels zu Hummingbird.

Checkliste nach dem Upgrade

Sie haben das Upgrade abgeschlossen und Ihr Back Office lädt. Feiern Sie noch nicht. Überprüfen Sie systematisch jede kritische Funktion Ihres Shops.

Front-Office-Tests

Back-Office-Tests

Überprüfung der Zahlungs-Gateways

Dieser Punkt verdient einen eigenen Abschnitt, da er den Umsatz direkt beeinflusst. Für JEDE Zahlungsmethode:

1. Geben Sie eine echte Testbestellung auf (oder nutzen Sie den Sandbox-Modus, falls verfügbar)
2. Überprüfen Sie, ob die Zahlung im Dashboard des Zahlungsanbieters erfasst wird
3. Überprüfen Sie, ob der Bestellstatus in PrestaShop korrekt aktualisiert wird
4. Testen Sie Erstattungen, wenn Ihr Workflow diese erfordert
5. Prüfen Sie Webhook-/IPN-URLs — das Upgrade hat möglicherweise URL-Strukturen geändert

Versand-Überprüfung

• Überprüfen Sie, ob alle Versanddienstleister korrekte Tarife für verschiedene Zonen anzeigen
• Testen Sie Schwellenwerte für kostenlosen Versand
• Wenn Sie Echtzeit-Versandkostenberechnung (API-basiert) nutzen, prüfen Sie, ob die Verbindung noch funktioniert
• Prüfen Sie, ob die Eingabe von Sendungsverfolgungsnummern und Benachrichtigungs-E-Mails funktionieren

Cron-Jobs

Überprüfen Sie jede automatisierte Aufgabe, die nach Zeitplan läuft:

• E-Mails bei Warenkorbabbruch
• Lagerbestandssynchronisation
• Feed-Generierung (Google Shopping, Facebook usw.)
• Sitemap-Generierung
• Währungskurs-Aktualisierungen
• Alle benutzerdefinierten Cron-Skripte

Cron-URLs ändern sich häufig zwischen Hauptversionen. Aktualisieren Sie Ihre Crontab-Einträge:

# Check your current cron jobs
crontab -l

# PS 9 cron URLs may have changed � verify each one loads correctly
curl -s -o /dev/null -w "%{http_code}" "https://yourshop.com/modules/yourmodule/cron.php?token=XXXXX"

SEO-Überprüfung

• Überprüfen Sie, ob benutzerfreundliche URLs noch funktionieren (Kategorieseiten, Produktseiten)
• Stellen Sie sicher, dass Ihre Sitemap korrekt generiert wird
• Prüfen Sie, ob die robots.txt korrekt ist
• Testen Sie wichtige Landingpages, die gut ranken — stellen Sie sicher, dass sie noch unter denselben URLs existieren
• Wenn sich URLs geändert haben, richten Sie sofort 301-Weiterleitungen ein

Häufige Upgrade-Probleme und Lösungen

Weißer Bildschirm (White Screen of Death)

Das häufigste Problem nach dem Upgrade. Sie sehen eine leere weiße Seite ohne Fehlermeldung.

Lösung:

1. Aktivieren Sie den Debug-Modus, indem Sie config/defines.inc.php bearbeiten:

   define('_PS_MODE_DEV_', true);

2. Laden Sie die Seite neu — jetzt sollten Sie den tatsächlichen PHP-Fehler sehen
3. Wenn Sie immer noch einen weißen Bildschirm sehen, prüfen Sie die PHP-Fehlerprotokolle:

   # Apache
   tail -50 /var/log/apache2/error.log
   
   # Nginx + PHP-FPM
   tail -50 /var/log/php-fpm/error.log
   
   # PrestaShop's own log
   tail -50 /var/www/html/var/logs/prod.log

4. Häufige Ursachen:
   • PHP-Speicher erschöpft — erhöhen Sie memory_limit in der php.ini auf 512M
   • Fehlende PHP-Erweiterung — installieren Sie die erforderliche Erweiterung und starten Sie PHP neu
   • Dateiberechtigungsproblem — führen Sie chown -R www-data:www-data /var/www/html/var/ aus

500 Internal Server Error

Wird in der Regel durch .htaccess-Probleme oder PHP-Konfigurationsfehler nach dem Upgrade verursacht.

Lösung:

# Check if .htaccess is the problem � temporarily rename it
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# If the site loads without .htaccess, regenerate it from back office:
# Shop Parameters ? Traffic & SEO ? Generate .htaccess file

# Or manually restore the default PS 9 .htaccess

Prüfen Sie außerdem:

• Apache mod_rewrite ist aktiviert: a2enmod rewrite && systemctl restart apache2
• Ihr Apache Virtual Host erlaubt .htaccess-Überschreibungen: AllowOverride All
• Die PHP-Version ist tatsächlich 8.2+ für den Webprozess (nicht nur für CLI)

Modulkonflikte nach dem Upgrade

Symptome: Back Office lädt nur teilweise, Fehler in bestimmten Bereichen, JavaScript-Fehler in der Konsole.

Lösung — die Isolationsmethode:

1. Deaktivieren Sie ALLE nicht-nativen Module:

   # Via database if back office is broken
   mysql -u root -p prestashop -e "UPDATE ps_module SET active = 0 WHERE name NOT IN ('ps_banner','ps_contactinfo','ps_emailsubscription','ps_featuredproducts','ps_imageslider','ps_linklist','ps_mainmenu','ps_searchbar','ps_sharebuttons','ps_socialfollow','ps_wirepayment','ps_checkpayment');"

2. Cache leeren: rm -rf var/cache/*
3. Überprüfen Sie, ob der Shop nur mit nativen Modulen funktioniert
4. Aktivieren Sie Module einzeln und leeren Sie den Cache zwischen jedem Modul
5. Wenn Sie das problematische Modul gefunden haben, aktualisieren Sie es, ersetzen Sie es oder kontaktieren Sie den Anbieter

Fehlende oder defekte Übersetzungen

Nach dem Upgrade können einige Übersetzungszeichenfolgen fehlen oder als rohe Schlüssel angezeigt werden (wie Modules.YourModule.SomeString).

Lösung:

• Gehen Sie zu International → Übersetzungen und exportieren/importieren Sie Ihr Sprachpaket
• Für Modul-Übersetzungen setzen Sie die Übersetzungen des Moduls zurück: Deinstallieren und erneut installieren (Hinweis: Dies kann die Konfiguration zurücksetzen — sichern Sie sie vorher)
• PrestaShop 9 nutzt Symfonys Übersetzungssystem stärker — Übersetzungsdateien im alten Stil (in modules/yourmodule/translations/) müssen möglicherweise konvertiert werden

Cache-Probleme

Veralteter Cache steckt hinter einer überraschenden Anzahl von Problemen nach dem Upgrade. Im Zweifelsfall alles löschen:

# Nuclear cache clear
rm -rf var/cache/*

# Symfony cache rebuild
php bin/console cache:clear --env=prod --no-warmup
php bin/console cache:warmup --env=prod --no-optional-warmers

# Fix ownership after cache rebuild
chown -R www-data:www-data var/

# Also clear your browser cache � old cached JS/CSS can cause phantom issues

Bilder werden nicht angezeigt

Bildpfade oder das Bildabrufsystem können sich zwischen Versionen ändern.

Lösung:

• Thumbnails neu generieren: Design → Bildeinstellungen → Thumbnails neu generieren
• Prüfen Sie, ob die Berechtigungen des img/-Verzeichnisses korrekt sind
• Wenn Sie ein CDN verwenden, leeren Sie den CDN-Cache
• Stellen Sie sicher, dass das neue Bild-URL-Format dem entspricht, was Ihr Theme erwartet

Admin-Anmeldung funktioniert nicht

Die Passwort-Hashing-Algorithmen haben sich in PS 9 geändert (Symfonys MigratingPasswordHasher mit bcrypt/argon2). In den meisten Fällen funktionieren bestehende Passwörter, da der Hasher beim ersten Login automatisch migriert. Aber wenn Sie ausgesperrt sind:

# Reset admin password � PS 9 requires Symfony's password hasher
# Do NOT use raw MD5 or direct SQL UPDATE on the password field

# Instead, use PrestaShop's CLI (if available):
php bin/console prestashop:user:change-password --email=admin@yourshop.com

# Or create a temporary PHP script to reset the password properly
# (delete this file immediately after use!)

Lassen Sie niemals Passwort-Reset-Skripte auf Ihrem Server liegen. Erstellen Sie sie, verwenden Sie sie, löschen Sie sie — alles in einer Sitzung. Ein vergessenes Reset-Skript ist eine Sicherheitslücke.

Wann Sie einen Entwickler beauftragen sollten vs. Eigenleistung

Seien Sie ehrlich bei der Einschätzung Ihrer technischen Fähigkeiten. Ein fehlgeschlagenes Upgrade kann Sie Tage an Umsatz und Kundenvertrauen kosten. Hier ist ein realistischer Leitfaden:

Sie können es wahrscheinlich selbst machen, wenn:

• Sie von PS 8.2 auf 9.x upgraden (ein Versionssprung)
• Sie weniger als 10 Drittanbieter-Module haben, alle als PS9-kompatibel bestätigt
• Sie ein Standard-Theme verwenden (Classic → Hummingbird, oder ein gekauftes Theme mit PS9-Unterstützung)
• Sie sich mit SSH, Kommandozeile und Datenbankoperationen auskennen
• Sie eine funktionierende Staging-Umgebung zum Testen haben
• Ihr Shop keine benutzerdefinierten Overrides oder Core-Modifikationen hat

Sie sollten einen Entwickler beauftragen, wenn:

• Sie von PS 1.6.x oder frühem 1.7.x upgraden (großer Versionsabstand)
• Sie 20+ Module haben, insbesondere wenn einige Overrides verwenden
• Sie ein benutzerdefiniertes Theme haben, das auf Hummingbird portiert werden muss
• Ihr Shop benutzerdefinierte Core-Modifikationen oder Override-Dateien hat
• Sie sich mit der Kommandozeile oder Datenbankoperationen nicht wohl fühlen
• Ihr Shop erheblichen täglichen Umsatz generiert und Ausfallzeiten teuer sind
• Sie das Upgrade auf der Staging-Umgebung versucht haben und auf Probleme gestoßen sind, die Sie nicht lösen können

Worauf Sie bei einem Entwickler achten sollten

• Spezifische PrestaShop-Erfahrung — nicht nur „PHP-Entwickler“ oder „E-Commerce-Entwickler.“ PrestaShops Architektur ist einzigartig, und generische Entwickler werden abrechenbare Stunden damit verbringen, Dinge zu lernen, die ein PS-Spezialist bereits weiß.
• Speziell PS 9-Erfahrung — fragen Sie, ob bereits PS 9-Upgrades durchgeführt wurden. Die Symfony 6.4-Migration hat spezifische Fallstricke.
• Ein klarer Projektplan — der Vorschlag sollte umfassen: Audit → Staging-Upgrade → Tests → Produktions-Upgrade → Überwachung.
• Support nach dem Upgrade — Probleme treten oft 1–2 Wochen nach dem Upgrade auf, wenn Randfälle ausgelöst werden. Stellen Sie sicher, dass Support enthalten ist.

Typische Kostenrahmen

Dies sind grobe Schätzungen basierend auf Marktpreisen 2025–2026:

• Einfaches Upgrade (PS 8.x → 9.x, wenige Module, Standard-Theme): 500–1500 EUR
• Mittleres Upgrade (PS 1.7.x → 9.x, Theme-Portierung, moderate Modulanzahl): 2000–5000 EUR
• Komplexes Upgrade (PS 1.6.x → 9.x, kompletter Neuaufbau, viele benutzerdefinierte Module): 5000–15000+ EUR

Diese Preise spiegeln die Realität wider, dass ein Major-Version-Upgrade keine Ein-Klick-Aktion ist. Wenn Ihnen jemand 200 EUR für ein PS 1.6 → PS 9-Upgrade anbietet, versteht diese Person entweder den Umfang nicht oder wird Abkürzungen nehmen, die Sie später mehr kosten werden.

Rollback-Plan: Wenn etwas schiefgeht

Sie haben Backups erstellt (haben Sie doch, oder?). So verwenden Sie sie, wenn das Upgrade katastrophal fehlschlägt.

Rollback vom Auto-Upgrade

Wenn Sie das 1-Click Upgrade-Modul verwendet haben und es ein eigenes Backup erstellt hat:

1. Navigieren Sie zu Back Office → Module → 1-Click Upgrade
2. Klicken Sie auf „Rollback“ und wählen Sie das Backup vor dem Upgrade
3. Das Modul stellt sowohl Dateien als auch Datenbank wieder her

Wenn das Back Office komplett unzugänglich ist, müssen Sie manuell wiederherstellen:

Manueller Rollback — Datenbank

# Drop the current (broken) database and recreate it
mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"

# Import your backup
mysql -u root -p prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# For Docker:
docker exec -i my-shop-db mysql -u root -p'PASSWORD' -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
docker exec -i my-shop-db mysql -u root -p'PASSWORD' prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

Manueller Rollback — Dateien

# Remove the upgraded files
rm -rf /var/www/html/*

# Restore from your backup
tar -xzf ~/prestashop_files_pre_ps9_XXXXXXXX_XXXXXX.tar.gz -C /

# Fix permissions
chown -R www-data:www-data /var/www/html/

# Clear cache
rm -rf /var/www/html/var/cache/*

Überprüfen Sie, ob der Rollback funktioniert hat

1. Rufen Sie das Front Office auf — lädt Ihr Shop?
2. Rufen Sie das Back Office auf — können Sie sich einloggen?
3. Prüfen Sie einige Bestellungen — sind die Daten intakt?
4. Geben Sie eine Testbestellung auf — funktioniert der Checkout?
5. Deaktivieren Sie den Wartungsmodus, sobald alles bestätigt funktioniert

Versuchen Sie nach einem Rollback NICHT sofort erneut das Upgrade. Analysieren Sie zuerst, was schiefgelaufen ist. Prüfen Sie die Upgrade-Protokolle, identifizieren Sie den fehlgeschlagenen Schritt, recherchieren Sie den spezifischen Fehler und beheben Sie die Grundursache in Ihrer Staging-Umgebung, bevor Sie die Produktionsumgebung erneut anfassen.

Der Notfall „Kein Backup“

Wenn Sie keine Backups erstellt haben (es passiert — tun wir nicht so, als wäre es anders), sind Ihre Möglichkeiten begrenzt, aber nicht null:

• Hosting-Anbieter-Backups: Viele Hoster bewahren tägliche Backups für 7–30 Tage auf. Prüfen Sie Ihr Hosting-Panel oder kontaktieren Sie sofort den Support.
• Datenbank-Binär-Logs: Wenn MySQL-Binary-Logging aktiviert ist, ist eine Point-in-Time-Recovery möglicherweise möglich. Das erfordert Expertenwissen.
• Das Backup des Autoupgrade-Moduls: Wenn Sie beim Upgrade „Backup erstellen“ aktiviert haben, suchen Sie in /admin/autoupgrade/backup/ nach den Backup-Dateien des Moduls.
• Akzeptieren und weiter nach vorn: Wenn eine Wiederherstellung nicht möglich ist, konzentrieren Sie sich darauf, den aktualisierten Shop zu reparieren, statt zurückzugehen. Manchmal ist vorwärts der einzige Weg.

Zusammenfassung: Der Upgrade-Pfad auf einen Blick

1. Prüfen — Server-Anforderungen, Modul-Kompatibilität, Theme-Kompatibilität
2. Sichern — Datenbank (mysqldump), Dateien (tar), Konfigurationsnotizen
3. Staging — das gesamte Upgrade zuerst in einer Staging-Umgebung testen
4. Planen — ein verkehrsarmes Zeitfenster mit Puffer für Probleme wählen
5. Upgraden — Wartungsmodus ein, Upgrade durchführen, Caches leeren
6. Testen — Front Office, Back Office, Checkout, Zahlungen, Versand, E-Mails
7. Überwachen — Fehlerprotokolle 48 Stunden nach dem Go-Live beobachten
8. Aufräumen — Debug-Modus deaktivieren, temporäre Dateien entfernen, Dokumentation aktualisieren

PrestaShop 9 ist eine erhebliche Verbesserung gegenüber seinen Vorgängern. Die Symfony 6.4-Grundlage, die PHP 8.2+-Anforderung und der Twig-basierte Admin-Bereich schaffen eine stabilere, schnellere und besser wartbare Plattform. Das Upgrade erfordert sorgfältige Planung, aber das Ergebnis ist die Mühe wert — eine moderne E-Commerce-Engine, die Ihnen viele Jahre gute Dienste leisten wird.

Nehmen Sie sich Zeit, testen Sie gründlich und überspringen Sie die Backups nicht. Ihr zukünftiges Ich wird es Ihnen danken.