PrestaShop 9: Checkliste für Migration und Upgrade

So würden wir vorgehen

Bei einem geeigneten PrestaShop-1.7- oder 8-Shop mit gepflegten Modulen und begrenzten Änderungen würden wir zuerst das Update einer Staging-Kopie testen. Bei einem 1.6-Shop, einem nicht unterstützten Theme oder umfangreichen individuellen Änderungen würden wir in der Regel zuerst einen frischen PrestaShop-9-Aufbau mit zugeordneter Datenmigration bewerten. Ein Neuaufbau ist ein zu prüfender Weg, keine automatische Voraussetzung für jeden angepassten Shop: Eine einzelne fehlerhafte Integration lässt sich oft für sich allein anpassen oder ersetzen, wie das Beispiel unten zeigt.

Der PrestaShop Upgrade Service beginnt mit einer kostenlosen Prüfung Ihrer Version, PHP-Umgebung, Hostingumgebung, Ihres Themes und Ihrer Module. Sie erhalten vor Beginn ein schriftliches Festpreisangebot. Die Arbeiten erfolgen auf Staging, während der Live-Shop weiter Bestellungen annimmt; der Wechsel von 1.6 ist eine Migration mit einem höheren Angebotspreis.

Bevor Sie einen der beiden Wege freigeben, fordern Sie die Kompatibilitätsbefunde, den Datenumfang, die Abnahmeprüfungen und den Rücksetzungsplan an.

Ein unterstütztes Ziel und einen passenden Weg für Ihren Shop wählen

Eine große PrestaShop-Migration kann PHP, Frameworkkomponenten, Verwaltungsseiten, Themes und Erweiterungspunkte verändern. Inventarisieren Sie den genauen Shop, bevor Sie Update oder Neuaufbau wählen. Halten Sie eine schriftliche Abnahmecheckliste und einen Entscheidungspunkt für die Rückkehr zum alten Stand fest.

Stand 26. Oktober 2026 ist PrestaShop 9.2 verfügbar. Wählen Sie eine mit Sicherheitskorrekturen versehene Zielversion, die Ihre Zahlungs-, Versand-, Theme- und Integrationsanbieter unterstützen. Ein Shop kann noch laden und dennoch außerhalb der Softwarewartung liegen.

Die offizielle Wartung von PrestaShop 1.6 endete am 30. Juni 2019; spätere ehrenamtliche Arbeit war eine separate Initiative. Siehe die Wartungsmitteilung und Erläuterung zur ehrenamtlichen Wartung. Die reguläre Wartung von 1.7 endete mit der Veröffentlichung von 9.0.

Der Updater für die erste 1.6-Stufe wird nicht mehr gewartet. Proben Sie ihn isoliert und bewahren Sie nach jeder Stufe einen Snapshot auf. Ein sauberer Neuaufbau ist eine separate Option, kein Beweis dafür, dass stufenweise Updates technisch unmöglich sind. Prüfen Sie die offiziellen Update-Assistant-Wege.

Welchen Weg Sie auch prüfen: Checkout, Auftragsabwicklung und Wiederherstellung auf Staging entscheiden, ob er tragfähig ist. Eine Kopie, die startet und den Katalog anzeigt, hat die Prüfung noch nicht bestanden.

Vorbereitung verringert das Risiko, kann aber Fehler oder Infrastrukturausfälle nicht ausschließen. Versprechen Sie keine feste Upgrade-Dauer, Ausfallzeit oder Ranking-Erholung auf Grundlage einer Modulanzahl oder Kataloggröße, und wählen Sie keinen Weg aufgrund eines Versprechens universeller Kompatibilität.

Beispiel: den Shop behalten, das Hindernis ersetzen

Angenommen, ein Shop auf PrestaShop 8 hat ein gepflegtes Theme und funktionierende Katalogwerkzeuge, aber seine individuelle Versanddienstleister-Anbindung scheitert auf der vorgeschlagenen Zielversion. Bitten Sie den Entwickler, diese Anbindung abzugrenzen, ihre Anforderungen an Daten und Versandetiketten zu ermitteln und eine Anpassung oder einen Ersatz auf Staging zu testen. Dieser Befund allein rechtfertigt keinen Neuaufbau des gesamten Katalogs. Ein 1.6-Shop mit nicht mehr unterstütztem Theme, direkten Core-Änderungen und einer undokumentierten Bestandsanbindung benötigt dagegen vor Arbeitsbeginn einen Kostenvergleich beider Wege.

Lassen Sie sich den gewählten Weg schriftlich geben. Bei einem Update ist das die stufenweise Abfolge mit Ausgangsversion, Updater, Ziel und PHP-Laufzeit jeder Stufe sowie dem Prüfpunkt, von dem aus sich jede Stufe wiederherstellen lässt (siehe den Abschnitt zur PHP-Kompatibilität unten). Bei einem Neuaufbau sind es die Datenzuordnung und das Verfahren für die finale Übertragung (siehe den Abschnitt zum sauberen Shop unten).

Laufende Version und Serveranforderungen ermitteln

Lesen Sie die laufende Shopversion im Backoffice-Footer oder unter Erweiterte Einstellungen > Informationen ab. Bestätigen Sie, dass Sie im Produktivsystem statt in einer alten Staging-Kopie sind. Eine Modulversion ist nicht die Shopversion.

Das ältere 1.6 definiert _PS_VERSION_ häufig in config/settings.inc.php. PrestaShop 1.7/8 stellt die Anwendungsversion in app/AppKernel.php bereit. In PrestaShop 9.1 delegiert diese Klasse VERSION an src/Core/Version.php. Behandeln Sie eine kopierte Datei als Hinweis, nicht als Beweis eines vollständigen Deployments.

Nutzen Sie in Code mit bereits initialisiertem Shop _PS_VERSION_ und version_compare() für Kompatibilitätsprüfungen. Erfassen Sie Web-PHP-Version und CLI-PHP, Erweiterungen, Grenzen, Datenbankversion, aktives Theme und Modulversionen.

php -v
php -m
php -i | rg 'memory_limit|max_execution_time'
# Run through the actual database connection:
# SELECT VERSION();

mysql --version meldet die Client-Binärdatei und nicht zwingend den verbundenen Server. SELECT VERSION() identifiziert den über diese Verbindung erreichten Server. Auch CLI-PHP kann vom PHP-FPM-Pool abweichen, der den Shop bedient.

PrestaShop 9 dokumentiert eine Speicherempfehlung von 512M je Skript. Planen Sie anhand von Messungen zusätzliche Reserven für große Updates und PDF-/Importaufgaben ein. Prüfen Sie CURL, DOM, Fileinfo, GD, Iconv, Intl, JSON, Mbstring, OpenSSL, PDO/MySQL, SimpleXML und Zip sowie erforderliche Laufzeiteinstellungen. Siehe die Systemanforderungen.

Gepackte Produktivversionen enthalten Abhängigkeiten. Composer und Frontend-Buildtools werden für Quellcode-Buildabläufe benötigt, nicht für jedes gepackte Update.

Prüfen Sie Datenbankkompatibilität und Anbieterwartung getrennt. MySQL 8.0 wechselte im April 2026 in Sustaining Support; betrachten Sie es nicht automatisch als Ziel für neue Installationen. Wählen Sie eine gewartete Version, die zum genauen Shop und Hostingstack passt, und testen Sie ihr SQL-Verhalten. Siehe die MySQL-Lebenszyklusmitteilungen.

PHP-Kompatibilität in jeder Phase planen

Die folgende Übersicht zeigt Kompatibilität und empfiehlt nicht, alte PHP-Versionen öffentlich bereitzustellen:

Nutzen Sie für genaue Ausgangs-/Zielversionen die ältere Matrix, die PrestaShop-8-Matrix und die 9.2-Anforderungen.

PHP 7.4 erreichte sein Lebensende am 28. November 2022; der Sicherheitssupport für PHP 8.1 endete am 31. Dezember 2025. Prüfen Sie die unterstützten PHP-Zweige und die Liste abgekündigter Versionen. Kompatibilität macht eine alte Laufzeit nicht für eine neue öffentliche Bereitstellung geeignet.

1. Erfassen Sie die PHP-Anforderungen für Ausgangsshop, Updater, Updatephasen und Ziel, einschließlich der Laufzeit, die Importe und andere geplante Aufgaben ausführt.
2. Wählen Sie einen direkten Weg von 1.7 auf 9 nur, wenn die genaue Assistant-Version und das Ziel die Vorprüfung bestehen und Sie jede Phase mit kompatiblem PHP geprobt haben. Ausgang und Ziel haben keine allgemein unterstützte gemeinsame PHP-Version; umgehen Sie Anforderungen nicht und nehmen Sie keinen automatischen Laufzeitwechsel an.
3. Kann dieser Weg die Übergabe nicht zuverlässig abschließen, wählen Sie einen getesteten Zwischenweg oder eine saubere Migration.
4. Eine optionale Stufe von 1.7.8 auf 8.2 kann unter PHP 7.4 laufen; 8.2 kann anschließend unter PHP 8.1 für einen getesteten Übergang auf 9 laufen. Halten Sie diese abgekündigten Zwischenlaufzeiten isoliert und vorübergehend.
5. Wechseln Sie nach Erreichen des Ziels auf die gewählte gewartete PHP-Version, die der gesamte Stack unterstützt, und testen Sie erneut.

Stellen Sie eine live laufende 1.7-Installation nicht auf ein beliebiges PHP 8 um, nur weil der Hoster es anbietet oder um herauszufinden, ob die alte Installation startet: Klären Sie das auf Staging. Halten Sie Web, CLI und geplante Aufgaben auf demselben Stand. Setzen Sie PHP nur dann allein zurück, wenn auch die wiederhergestellten Anwendungsdateien und die Datenbank kompatibel sind.

Module, individuellen Code und Integrationen prüfen

Erstellen Sie ein Inventar aus Modulmanager und bereitgestelltem Dateisystem. Erfassen Sie Modulname, Version, Anbieter, Zweck, Shopzuordnungen, Konfiguration, Datenverantwortung, geplante Aufgaben und externe Endpunkte. Wählen Sie für jeden Eintrag ein kompatibles Update, einen Ersatz, die Entfernung oder ausdrücklich eingeplante Migrationsarbeiten.

Priorisieren Sie Zahlung, Checkout, Versanddienstleister, Steuern, Rechnungsstellung, ERP/PIM, Bestand, Feeds und E-Mail. Ein ladender Katalog beweist nicht, dass Sie Bestellungen annehmen und ausführen können.

• Lesen Sie für jedes Modul die angegebenen PrestaShop- und PHP-Bereiche sowie die Abhängigkeitsvorgaben. Bitten Sie Theme- und Modulanbieter, die Unterstützung für das genaue Ziel und die PHP-Version zu bestätigen, und testen Sie diese Aussage dann mit Ihrer Konfiguration.
• Prüfen Sie individuelle Overrides, kopierte Vorlagen, eigene Controller, Cron-Endpunkte, API-Clients, Callback-URLs und fest codierte Admin-Pfade. Beziehen Sie Änderungen ein, die direkt an Core- oder Moduldateien vorgenommen wurden.
• Prüfen Sie entfernte APIs und Übersetzungen gegen das genaue Ziel und reproduzieren Sie dann etwaige Fehler.
• Nutzen Sie generierte Backoffice-Links/-Routen statt zusammengesetzter Verzeichnisnamen und Token.
• Testen Sie Webservice-Schlüssel und neuere Admin-API-Clients/Scopes als separate Integrationen.
• Benennen Sie für jede Integration den Verantwortlichen, der Sandbox-Zugangsdaten, Testfälle und Unterstützung beim Start liefern kann.

PrestaShop 8 nutzt Symfony 4.4; 9 nutzt Symfony 6.4. Moderne Adminseiten verwenden Twig und Symfony, während ältere Controller Kompatibilitätswege behalten. Es ist nicht davon auszugehen, dass Render-Lebenszyklus oder Vorlagen-Override eines alten Controllers eine migrierte Seite steuert.

Tools::displayPrice() wurde in 9 entfernt. Nutzen Sie im passenden Kontext formatPrice($amount, $currencyIsoCode) der aktuellen Locale. Prüfen Sie alte Admin-Übersetzungsaufrufe und Legacy-Lebenszyklusmethoden einzeln, statt ein universelles Rezept für Konstruktor-/Eigenschaftszuweisungen vorzugeben.

Bevorzugen Sie geeignete unterstützte Hooks, Event-Subscriber und Symfony-Service-Dekoration. Legacy-Klassen-Overrides existieren für relevante Klassen weiter, können aber kollidieren und brauchen Signaturprüfungen. Prüfen Sie Hookparameter, Ausführung und Frontoffice-Markup unter dem gewählten Theme. Siehe den Leitfaden zur Codestruktur.

Aktualisieren Sie Module auf Staging in kontrollierter Reihenfolge. Sichern Sie Daten vor jeder Deinstallation oder Zurücksetzung. Deaktivieren Sie über den Modulmanager oder die unterstützte Aktion prestashop:module disable im vorgesehenen Shopkontext. Ein Update allein von module.active behandelt Shopzuordnungen nicht korrekt.

Fragen an Ihren Entwickler oder Ihre Agentur

• Für welche wesentlichen Module gibt es einen getesteten kompatiblen Build, und welche hängen von noch nicht angebotener Entwicklung oder einer neuen Lizenz ab?
• Welche Änderungen existieren nur in den bereitgestellten Dateien und nicht im Paket des Anbieters oder im Quellcode-Repository?
• Wer testet Zahlungen, Bestandsübertragungen, Versandetiketten und Buchhaltungsexporte mit den jeweiligen Anbietern?
• Welche Laufzeit verarbeitet Browseranfragen, und welche führt Importe und andere geplante Aufgaben aus?
• Welche Nachweise belegen den Abschluss, und wer entscheidet, ob eine fehlgeschlagene Prüfung den Start verhindert?

Bewahren Sie die Antworten beim Inventar auf. Kennzeichnen Sie einen unbekannten Anbieter oder eine undokumentierte Integration als ungeklärte Abhängigkeit und benennen Sie eine Person, die sie untersucht.

Wenn Sie unsere Module nutzen, zeigt Module Updates & Remote Assist die installierten Versionen und die für Ihre Lizenz verfügbaren Updates an und lässt Sie Installationen und Updates im Backoffice auswählen. Es ersetzt nicht das zusammenpassende Backup des gesamten Shops und die Wiederherstellungsprobe unten.

Zusammenpassende Backups erstellen und auf Staging proben

Sichern Sie vor jeder Änderung an Versionen, Schema, Modulen oder Themes den gesamten Shop und die zugehörige Datenbank, und halten Sie schriftlich fest, wie Sie zur ursprünglichen Installation zurückkehren. Beziehen Sie Dotfiles, hochgeladene Medien, Module, Moduldaten, Theme-Anpassungen und Konfiguration ein. Speichern Sie Webserver- und PHP-FPM-Konfiguration, SMTP-Einstellungen, Zahlungszugangsdaten, Webhook-URLs, geplante Aufgaben und CDN-Regeln in einer geschützten Betriebsdokumentation.

Das folgende Beispiel setzt einen geschützten MySQL-Loginpfad namens shop-backup und ein vorhandenes eingeschränktes Backupverzeichnis voraus. Wählen Sie vor der Nutzung den tatsächlichen Datenbanknamen und die Pfade.

mysqldump --login-path=shop-backup --single-transaction --quick prestashop > /srv/backups/prestashop-before-update.sql
tar -C /var/www -czf /srv/backups/prestashop-before-update-files.tar.gz html

Prüfen Sie Befehls-Exitstatus, verfügbaren Speicherplatz und Archivintegrität. Ein transaktionaler Dump setzt transaktionale Tabellen und keine kollidierenden Schemaänderungen voraus. Koordinieren Sie einen Datei-/Datenbanksnapshot und nutzen Sie bei Bedarf eine geeignete Schreibsperre. Schreiben Sie Passwörter nicht in Befehlsargumente oder öffentliche Archive.

Beziehen Sie in Docker die tatsächlichen persistenten Mounts/Volumes und Datenbankdaten oder einen logischen Dump ein. Dokumentieren Sie Image-/Laufzeitversionen und numerische Eigentümer. Allein das Containerimage zu kopieren bewahrt weder aktuelle Bestellungen noch hochgeladene Dateien.

1. Halten Sie ein Backup außerhalb des Servers unter separaten Zugangsdaten vor.
2. Bereiten Sie das isolierte Ziel vor, bevor die kopierte Anwendung oder eine geplante Aufgabe startet: eigene Datenbank, eigene Domain und eingeschränkter Zugang. Deaktivieren Sie echte Zahlungen, ausgehende Kundenmails, Live-Webhooks und geplante externe Schreibvorgänge, oder richten Sie sie auf Sandbox-Verbindungen und ein Testpostfach aus.
3. Stellen Sie dort Dateien und Datenbank wieder her. Bestätigen Sie, dass die Kopie wirklich die Staging-Datenbank und die Staging-Ziele nutzt und nicht nur eine andere Domain.
4. Prüfen Sie Katalog, Bestellanzahl, Bilder, Kundenanmeldungen und repräsentative Rechnungen.
5. Führen Sie das geplante Update oder die Migration einschließlich jedes PHP-Wechsels aus. Bewahren Sie Fehlermeldungen auf und dokumentieren Sie die Korrekturen.
6. Wiederholen Sie den Vorgang ausgehend von einem frischen zusammenpassenden Snapshot, damit das schriftliche Verfahren jeden erforderlichen Schritt enthält.
7. Proben Sie auch die Wiederherstellung: die Rückkehr zur ursprünglichen Installation aus zusammenpassenden Anwendungsdateien, Datenbank, Medien, Konfiguration und kompatiblem PHP.

Ändert die Probe Konfiguration von Hand, halten Sie diese Änderungen im Verfahren fest, damit sich die nächste Wiederherstellung nicht unbemerkt wieder mit dem Produktivsystem verbindet.

Backupdateien auf dem Datenträger beweisen keine Wiederherstellbarkeit, und Zeilenzahlen sind nützlich, aber kein vollständiger Wiederherstellungstest. Testen Sie die tatsächlichen Abläufe und Zugänge. Schützen Sie sensible Kundendaten auch auf Staging. Der Backup-Leitfaden behandelt den umfassenderen Wiederherstellungsprozess, und der Leitfaden zum privaten Staging hilft beim Einrichten der Kopie.

Den erprobten Update-Assistant-Ablauf ausführen

Nutzen Sie eine aktuelle gepackte Update-Assistant-Version, die zum Ausgangsshop passt, und folgen Sie dann ihrer Vorprüfung und dem Ablauf für das gewählte Ziel. Aktuelle Kanäle und Optionen unterscheiden sich von älteren „1-Click Upgrade“-Screenshots. Die Online-Zielauswahl hängt außerdem von der PHP-Laufzeit ab.

Prüfen Sie vor dem Start Anforderungen und Modulaktionen. Unterscheiden Sie vorübergehende Deaktivierung von vorgeschlagener Deinstallation oder Zurücksetzung, die Einstellungen oder Geschäftsdaten entfernen kann. Sichern und migrieren Sie diese Daten, bevor Sie eine destruktive Aktion akzeptieren. Beachten Sie den Assistant-Ablauf und die Hilfe der jeweiligen Version.

Wie ein solches Update von PrestaShop 8 auf 9 in der Praxis verläuft und wo es im Live-Betrieb hakt, zeigt die Case Study von 4eck Media.

Proben Sie genau diesen Ablauf zuerst auf Staging. Wiederholen Sie im Produktivsystem das schriftliche Verfahren, statt zu improvisieren:

1. Planen Sie die erprobte Umstellung und legen Sie einen Ausführenden, die Abnahmecheckliste, einen Entscheidungszeitpunkt für die Rücksetzung und die Fehler fest, die eine Rücksetzung auslösen.
2. Setzen Sie unter Shop-Einstellungen > Allgemein > Wartung Shop aktivieren auf Nein. Ergänzen Sie nur die vorgesehenen Wartungs-IPs und testen Sie von einer externen Adresse.
3. Kontrollieren Sie auch andere schreibende Systeme: Cronjobs, ERP-Importe, Warteschlangen und Callbacks. Wartungsmodus allein stoppt nicht jeden externen Schreibvorgang.
4. Erstellen Sie das letzte zusammenpassende Backup und halten Sie den letzten Abgleichpunkt für Bestellungen und Zahlungen, ausstehende Anbieter-Callbacks und Importe in der Warteschlange fest (siehe den Abschnitt zur Umstellung unten).
5. Führen Sie den getesteten Assistant-Weg und die PHP-Wechsel aus. Überwachen Sie Fortschritt und die richtigen PHP-/Anwendungsprotokolle.
6. Sichern Sie bei einem Fehler die Protokolle und diagnostizieren Sie den genauen Schritt. Aktualisieren Sie nicht blind die Seite, starten Sie nicht blind erneut und beenden Sie Prozesse nicht ungeprüft.
7. Bauen Sie nach Erfolg die Caches als vorgesehener Laufzeitbenutzer neu auf und prüfen Sie die Eigentümer generierter Dateien.
8. Aktivieren Sie freigegebene Module in kontrollierter Reihenfolge wieder und führen Sie vor der Wiedereröffnung die Abnahmetests aus, einschließlich Checkout, E-Mail, Callbacks, Weiterleitungen und Indexierungsbeschränkungen.

Zu den CLI-Cachebefehlen für ein kompatibles Ziel gehören:

php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

Nutzen Sie die richtige PHP-Binärdatei und Identität. Reparieren Sie Zugriffe auf ausgewählte beschreibbare Pfade, statt dem Webbenutzer rekursiv den gesamten Produktivcode zu übergeben. Halten Sie die Schreibsperre der Wartung bis zum Abschluss der Prüfungen aufrecht.

Einen sauberen Shop aufbauen und Daten zuordnen

Ein frisches Ziel ist sinnvoll, wenn Sie ein 1.6-Theme ersetzen, den Shop neu gestalten oder angesammelte Anpassungen entfernen. Es wird auf Staging aufgebaut und getestet, während der alte Shop weiter verkauft, sodass nur die finale Übertragung eine Schreibsperre braucht. Es bringt aber auch ein Datenmigrationsprojekt mit sich: Nicht jede Tabelle, jedes Passwort, jedes Dokument und jede Integration lässt sich unverändert übernehmen.

1. Installieren Sie das unterstützte Ziel an einem sauberen, geschützten Ort.
2. Wählen Sie ein kompatibles Theme und installieren Sie die benötigten kompatiblen Module.
3. Konfigurieren Sie Sprachen, Währungen, Steuern, Versanddienstleister, Zahlungen, E-Mail und rechtliche Seiten.
4. Ordnen Sie Kategorien, Produkte, Varianten, Eigenschaften, Attribute, Bilder, Bestand, Preise und SEO-Metadaten zu.
5. Ordnen Sie Kunden, Adressen und Kundengruppen zu und testen Sie dabei, ob Passwörter weiter gelten oder welcher Rücksetzungsablauf nötig ist.
6. Ordnen Sie historische Bestellungen, Rechnungen, Gutschriften, Zahlungen, Dokumentnummerierung und Beziehungen zu, soweit Service oder Buchhaltung sie benötigen.
7. Beziehen Sie modulspezifische Geschäftsdaten, Shopzuordnungen und Integrationsreferenzen ein, nicht nur die Katalogtabellen des Core.
8. Prüfen Sie Summen, Kennungen, Zuordnungen, Bildverweise und kundenseitigen Zugriff.

Der native CSV-Import unterstützt ausgewählte Katalog-/Kundenentitäten; er ist keine vollständige Migration historischer Bestellungen, Zahlungen und Dokumente. Ein dedizierter Migrationsdienst oder ein Skript benötigt eine ausdrückliche Feld-/Beziehungszuordnung und getestete Umwandlung.

Beispiel einer Datenzuordnung für die Migration

Fragen Sie, wie ein wiederholter Migrationslauf doppelte Datensätze vermeidet und wie geänderte oder gelöschte Quelldatensätze bei der finalen Übertragung behandelt werden. Die Probe ist nur nützlich, wenn dasselbe Verfahren erneut mit den finalen Daten laufen kann.

Stellen Sie keine handverlesene Auswahl von 1.6-Tabellen über einem frischen 9er-Schema wieder her. Tabellendefinitionen, Shop-/Sprachzeilen und Kennungen unterscheiden sich. Erhalten Sie Referenzen, Beziehungen und gesetzliche Dokumentnummerierung mit einem schemabewussten Verfahren.

Passwort-Hashes sind Einwegwerte. Ob Anmeldungen erhalten bleiben, hängt vom Migrationswerkzeug, von Legacy-Schlüsseln und der Hashing-Unterstützung des Ziels ab; das bloße Kopieren von Kundenzeilen stellt nicht sicher, dass Passwörter weiter gelten. Testen Sie echte migrierte Konten auf dem isolierten Ziel. Sind Rücksetzungen nötig, nutzen Sie den unterstützten Ablauf zum Zurücksetzen des Passworts und stimmen Sie vor dem Start eine klare Kundenkommunikation ab.

Die finale Übertragung der seit dem Probe-Snapshot vorgenommenen Änderungen erfolgt bei der Umstellung (siehe unten); verlangen Sie das schriftliche Verfahren dafür zusammen mit der Datenzuordnung.

Ein kompatibles Theme behalten oder ein Child-Theme erstellen

Ein Core-Upgrade erfordert nicht grundsätzlich den Wechsel zu Hummingbird. Classic bleibt in relevanten 9er-Versionen verfügbar. Sie können ein getestetes kompatibles Classic-basiertes Theme behalten oder eine separate Theme-Migration planen. Ein 1.6-Theme benötigt für modernes PrestaShop Ersatz oder eine umfangreiche Portierung.

Behalten Sie ein kompatibles Theme, wenn es die erforderlichen Abläufe besteht; ein Core-Upgrade allein begründet keinen Bedarf für ein Redesign. Behandeln Sie ein Redesign als separat abgegrenzte Arbeit mit eigenen Abnahmeprüfungen. Kann das aktuelle Theme nicht auf das Ziel mitgehen, wird das Frontoffice auf beiden Wegen neu aufgebaut, was für die Prüfung eines sauberen Shops spricht.

Hummingbird wurde bei frischen 9.1-Installationen zum Standard. Es nutzt Bootstrap 5.3 und CSS-Custom-Properties neben einem SCSS-Build. Änderungen von Laufzeitvariablen und Änderungen mit Sass-/Buildpipeline sind unterschiedliche Aufgaben. Testen Sie Hooks, Selektoren, responsive Layouts und Drittanbieter-Markup.

Fragen Sie bei einem gekauften Theme nach der genauen Kompatibilität mit Ziel und PHP, dem Updateweg, der Lizenzabdeckung und der Unterstützung für Checkout-Module. Gehen Sie nicht davon aus, dass ein Theme funktioniert, nur weil seine Vorlagen eine Startseite darstellen. Testen Sie bei einem Theme-Wechsel den Katalog, die Modulpositionen, die mobilen Bedienelemente und den Checkout mit Ihren echten Produkten.

Ein vollständiger Einstieg in ein Child-Theme

Dieses Beispiel setzt voraus, dass Hummingbird installiert ist und die Befehle im Shopstamm ausgeführt werden. Es erstellt das Konfigurationsverzeichnis, erbt Ressourcen des übergeordneten Themes und registriert ausdrücklich ein separates Child-Stylesheet.

mkdir -p themes/shop-child/config themes/shop-child/assets/css themes/shop-child/templates
cp themes/hummingbird/preview.png themes/shop-child/preview.png

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

parent: hummingbird
name: shop-child
display_name: Shop Child
version: 1.0.0
author:
  name: Shop Team
assets:
  use_parent_assets: true
  css:
    all:
      - id: shop-child-overrides
        path: assets/css/shop-overrides.css
        media: all
        priority: 1100

Erstellen Sie themes/shop-child/assets/css/shop-overrides.css:

body { --shop-child-ready: 1; }

Aktivieren Sie das Child-Theme über Design > Theme & Logo. Bauen Sie die Caches neu auf, öffnen Sie die Netzwerkansicht des Browsers und bestätigen Sie, dass Ressourcen des übergeordneten Themes und shop-overrides.css Status 200 liefern. Prüfen Sie am body die berechnete Custom-Property --shop-child-ready. Damit prüfen Sie das Laden des Stylesheets, bevor Sie echte Designänderungen ergänzen.

Kopieren Sie nur Vorlagen, die Sie ändern müssen, und erhalten Sie deren Pfad unter templates/. Vergleichen Sie sie später mit Updates des übergeordneten Themes. Siehe die Child-Theme-Struktur und den Child-Theme-Leitfaden.

URLs, Indexierungseinstellungen und externe Callbacks erhalten

Erstellen Sie das Inventar der alten URLs aus Katalog, Crawls, Sitemaps, Protokollen und Search-Console-Daten. Die Indexierungsbeispiele der Search Console sind kein vollständiger Export aller indexierten URLs. Beziehen Sie von Modulen gesteuerte URL-Muster ein, damit eine geänderte Route nicht unbemerkt Adressen unbrauchbar macht, die Kunden oder externe Systeme bereits nutzen.

Erhalten Sie funktionierende URLs nach Möglichkeit. Nutzen Sie für geänderte Entsprechungen getestete permanente Weiterleitungen wie 301 oder 308. Prüfen Sie endgültige Inhalte, Canonical-Tags, interne Links, Sprachalternativen und Feeds. Leiten Sie gelöschte Seiten ohne passenden Bezug nicht zur Startseite weiter und versprechen Sie keinen festen Erholungszeitraum.

Nutzen Sie ein Sitemap-Modul wie gsitemap oder einen anderen implementierten Generator; ein Core-Upgrade schafft nicht selbst einen vollständigen XML-Sitemap-Ablauf. Prüfen Sie vor der Einreichung erfolgreiche, indexierbare kanonische URLs. Entfernen Sie Staging-noindex-/Authentifizierungsbeschränkungen nur am vorgesehenen produktiven Ziel.

Öffnen Sie zum Beispiel eine alte Produktadresse in jeder relevanten Sprache und folgen Sie ihrer Weiterleitung zum entsprechenden Live-Produkt. Prüfen Sie die endgültige kanonische Adresse, die Sprachverknüpfungen und den Sitemap-Eintrag. Kontrollieren Sie, dass das Live-Ziel die Zugangsbeschränkungen und die noindex-Einstellung des Staging verloren hat, während die Staging-Kopie geschützt bleibt.

Aktualisieren Sie Zahlungs-Webhooks/IPNs, ERP-Endpunkte, Feed-URLs, E-Mail, Sendungsverfolgung und geplante Aufgaben, wenn sich Domain oder Pfad ändern. Testen Sie authentifizierte Vorgänge, statt einen HTTP-Status 200 allein als Beweis dafür zu werten, dass ein Cronjob seine fachliche Aufgabe erledigt hat.

Der Leitfaden zu URLs und Weiterleitungen enthält Zuordnung, Serverbeispiele und Startprüfungen.

SEO Revolution unterstützt Abläufe für Weiterleitungen und Sitemaps; nutzen Sie für die Konfiguration seine Modulhilfe.

Smart SEO Friendly URL Manager unterstützt individuelle Routen und eine URL-Historie; nutzen Sie seine Modulhilfe, wenn Sie diese Muster erhalten oder ändern.

Den Shop vor der Wiedereröffnung testen

Führen Sie diese Prüfungen bei jeder Staging-Probe und vor der Wiedereröffnung erneut am produktiven Ziel aus. Sammeln Sie für jeden Bereich Nachweise, keinen bloßen Eindruck.

Prüfen Sie den Zahlungseinzug im Dashboard des Anbieters, nicht nur den Bestellstatus. Bestätigen Sie die erwarteten Rechnungen, E-Mails und Bestandsänderungen und vermeiden Sie unbeabsichtigte doppelte Belastungen. Nutzen Sie die Sandboxes der Anbieter, wo verfügbar; stimmen Sie jede kontrollierte Live-Transaktion mit geringem Betrag vorab ab und gleichen Sie sie ab, damit Tests keine unbeabsichtigten Belastungen, Sendungen oder Kundennachrichten auslösen.

Aus der Checkliste realistische Testwarenkörbe machen

• Verwenden Sie einen Gastwarenkorb und einen Warenkorb eines bestehenden Kunden einschließlich relevantem Gruppenpreis, Gutschein und Lieferziel. Vergleichen Sie Steuern und Versandkosten unter denselben Bedingungen mit der Quelle.
• Testen Sie Warenkörbe knapp unter und über einer konfigurierten Grenze für kostenlosen Versand oder Rabatt. Beziehen Sie unterschiedliche Steuersätze oder Geschäftskundenfälle ein, sofern der Shop diese verwendet.
• Schließen Sie eine Sandbox-Zahlung ab, verlassen Sie den Ablauf vor der Rückkehr zum Shop und bestätigen Sie, dass der Anbieter-Callback dennoch den erwarteten Bestellstatus erzeugt. Wiederholen Sie einen Callback mit den unterstützten Testwerkzeugen des Anbieters und prüfen Sie auf doppelte Bestellungen, Nachrichten oder Bestandsänderungen.
• Führen Sie eine Erstattung über den vereinbarten Ablauf aus und prüfen Sie Anbieterdatensatz, Gutschrift und Bestandsbehandlung. Ein geänderter Bestellstatus allein weist keine Rückzahlung nach.

Dokumentieren Sie für jeden Fall Ausgangswarenkorb, erwartetes Ergebnis, beobachtetes Ergebnis und Nachweise. Lassen Sie die Mitarbeiter, die Bestellungen abwickeln, ihren eigenen Ablauf abnehmen.

Bewahren Sie Protokolle während der ersten vollständigen Betriebszyklen auf: Geplante Importe, Abrechnung, Retouren und Spitzenlast können beim Start übersehene Fälle aufdecken. Vergleichen Sie Checkout-Erfolg, Zahlungseingänge, Servicewarteschlangen und wichtige Einstiegsseiten mit dem Ausgangsstand.

In einem geplanten Zeitfenster umstellen

Verkaufen Sie während Vorbereitung und Probe weiter; nur die finale Umstellung braucht eine kontrollierte Schreibpause. Führen Sie sie als eigenes erprobtes Verfahren aus, mit einem Ausführenden, der Abnahmecheckliste und vorab vereinbarten Fehlerbedingungen, die eine Rücksetzung auslösen.

1. Stoppen Sie den Checkout des alten Shops und frieren Sie die anderen schreibenden Systeme ein: Wartungsmodus plus Cronjobs, Importe, Warteschlangen und Callbacks, wie in Schritt 2 und 3 des Update-Assistant-Ablaufs oben. Das gilt beim Neuaufbau auch für den alten Shop.
2. Halten Sie den Abgleichpunkt fest: das letzte abgeglichene Bestell- und Zahlungsereignis, ausstehende Anbieter-Callbacks, Importe in der Warteschlange und Bestandsänderungen. Vereinbaren Sie mit jedem Anbieter, wo verzögerte Ereignisse empfangen oder erneut eingespielt werden und wer sie prüft, statt Callbacks blind zu blockieren.
3. Erstellen Sie das letzte zusammenpassende Backup.
4. Update-Weg: Wenden Sie das erprobte Verfahren auf diesen finalen Produktivstand an oder nutzen Sie eine separat erprobte Übertragungsmethode, die alle zwischenzeitlichen Änderungen erhält. Übernehmen Sie keine alte Staging-Datenbank unverändert in den Produktivbetrieb: Ihr fehlt jede Bestellung seit dem Probe-Snapshot.
5. Neuaufbau-Weg: Übertragen Sie die letzten Änderungen seit dem Probe-Snapshot (Bestellungen, Kunden, Bestand, Zahlungen und geänderte Moduldaten) und gleichen Sie sie mit der Quelle ab.
6. Schließen Sie die Prüfungen am Ziel ab, die vor dem Wechsel möglich sind. Schalten Sie das Live-Ziel mit dem erprobten Verfahren um und prüfen Sie dann Checkout, E-Mail, Anbieter-Callbacks, Weiterleitungen und Indexierungseinstellungen über die produktiven Routen, bevor Sie den Checkout wieder öffnen. Halten Sie die separate Staging-Kopie geschützt.
7. Bleibt nach dem Umstieg eine separate alte Installation bestehen, halten Sie sie isoliert und schreibgeschützt für die berechtigte Einsicht. Bewahren Sie bei einem Update der bestehenden Installation den zusammenpassenden Snapshot vor dem Update und das getestete Wiederherstellungsverfahren auf. Lassen Sie nur den gewählten produktiven Checkout beschreibbar; beide Checkouts wieder zu öffnen, um den Abgleich zu umgehen, erzeugt zwei konkurrierende Bestellströme.
8. Überwachen Sie den Shop über die relevanten Import-, Abwicklungs- und Zahlungszyklen hinweg.

Häufige Probleme nach dem Update diagnostizieren

Beginnen Sie mit der ersten sicheren Prüfung: Sichern Sie die Nachweise und reproduzieren Sie das Problem auf geschütztem Staging mit der vorgesehenen Laufzeit und den vorgesehenen Erweiterungen, bevor Sie den Live-Shop ändern.

• Weiße Seite oder 500: Prüfen Sie zuerst die Protokolle von Webserver, PHP-FPM und PrestaShop und sichern Sie die Exception. Aktivieren Sie auf geschütztem Staging vorübergehend den Debugmodus, um die Exception zu ermitteln, und schalten Sie ihn danach wieder aus. Prüfen Sie Erweiterungen, Speicher, inkompatiblen Code und beschreibbare Pfade.
• Rewrite-Fehler: Sichern Sie individuelle Regeln und prüfen Sie Apache-Module/AllowOverride oder Nginx-Locations. Testen Sie Regeländerungen im vorgesehenen Kontext; das öffentliche Entfernen von .htaccess kann auch Schutzmaßnahmen entfernen.
• Modulkonflikt: Nutzen Sie die unterstützten Aktionen zum Deaktivieren von Modulen und isolieren Sie Änderungen auf der Kopie. Führen Sie kein globales SQL-Update des active-Felds mit einer geratenen Liste nativer Module aus, und setzen Sie Module bei einem Live-Upgrade nicht ohne Backup, Reproduktion auf Staging und Rücksetzungsplan zurück und deinstallieren Sie sie nicht.
• Fehlende Übersetzungen: Prüfen Sie Domainnamen, Übersetzungsdateien/-kataloge, Sprach-/Shopkontext und Caches. Neuinstallation ist keine allgemeine Übersetzungskorrektur und kann Moduldaten löschen.
• Veraltetes CSS oder JavaScript: Prüfen Sie zuerst die Asset-URLs, bauen Sie dann die Anwendungs- und Theme-Caches neu auf und leeren Sie den betreffenden CDN- oder Browsercache.
• Fehlende Bilder: Prüfen Sie Asset-Adressen, Pfade und Berechtigungen, bevor Sie etwas neu generieren, und generieren Sie anschließend bei Bedarf die benötigten Vorschaubilder neu. Prüfen Sie das CDN separat.
• Admin-Anmeldung: Prüfen Sie URL, Cookies, HTTPS, Mitarbeiterstatus, Authentifizierungsprotokolle und die Zustellung der Rücksetzungsmail. Nutzen Sie den integrierten Ablauf zum Zurücksetzen von Mitarbeiterpasswörtern.

Der PrestaShop-Core nutzt seinen Crypto-Hashing-Dienst einschließlich bcrypt und Legacy-MD5-Prüfung. Schreiben Sie nicht die gesamte Passwortverarbeitung des Shops Symfonys MigratingPasswordHasher zu. Moderne Backoffice-Authentifizierung und Frontoffice-Cookies nutzen unterschiedliche Mechanismen.

In diesem Core gibt es keinen standardmäßigen Wiederherstellungsbefehl prestashop:user:change-password. Vermeiden Sie rohe Passwort-SQL-Befehle und öffentliche Resetskripte. Reparieren Sie bei fehlgeschlagenen Resetmails die Zustellung oder nutzen Sie ein ausdrücklich unterstütztes administratives Wiederherstellungsverfahren.

Nutzen Sie zur detaillierten Diagnose den Leitfaden zur Fehlerbehebung.

Sicher wiederherstellen und das Ergebnis übergeben

Legen Sie vor dem Start fest, welcher Fehler eine Rücksetzung auslöst. Bewahren Sie Protokolle und den fehlgeschlagenen Zustand zur Diagnose auf. Eine Wiederherstellung muss zusammenpassende Dateien, Datenbank, PHP-Laufzeit, Konfiguration und persistente Medien verbinden.

1. Halten Sie den Shop im Wartungsmodus und kontrollieren Sie externe Schreiber.
2. Prüfen Sie, ob der getestete Wiederherstellungsablauf des Assistant das vorgesehene Backup vor dem Update nutzen kann.
3. Verwenden Sie für eine manuelle Wiederherstellung ein sauberes Ziel und eine separate leere Datenbank.
4. Stellen Sie den vollständigen zusammenpassenden Snapshot einschließlich versteckter Dateien wieder her. Legen Sie kein Archiv über aktualisierten Code und nehmen Sie nicht an, rm -rf /var/www/html/* habe Dotfiles entfernt.
5. Verbinden Sie die wiederhergestellte Umgebung mit ihrer Datenbank und der richtigen Domain/Laufzeit, reparieren Sie benötigte Rechte und bauen Sie generierte Caches neu auf.
6. Gleichen Sie alle nach dem Snapshot angenommenen Bestellungen, Zahlungen oder externen Ereignisse ab, bevor Sie wieder öffnen. Wer das Backup von gestern wiederherstellt, nachdem neue Bestellungen eingegangen sind, braucht einen ausdrücklichen Abgleichplan: Eine Wiederherstellung löscht weder die Transaktion eines Anbieters noch einen Vorgang im Lager.
7. Testen Sie Anmeldung, Katalog, Checkout, E-Mail und Integrationen anhand der Wiederherstellungscheckliste.

Eine reine Datenbankrücksetzung bei neuen Dateien hinterlässt eine gemischte Installation. Wurde PHP geändert, stellen Sie auch kompatible Web- und CLI-Versionen wieder her. Halten Sie die fehlgeschlagene Umgebung isoliert, bis Sie die zur Untersuchung benötigten Protokolle und Daten haben.

Fragen Sie ohne ausreichendes Backup sofort den Hoster nach Snapshots und Aufbewahrung, prüfen Sie das Backupinventar des Assistant und bewerten Sie bei vorhandenen Binärprotokollen eine zeitpunktgenaue Wiederherstellung. Ein fehlgeschlagenes Update lässt sich nicht sicher durch Kopieren einiger alter Dateien rückgängig machen. Fachkundige Wiederherstellung oder eine Vorwärtskorrektur kann nötig sein.

Reproduzieren Sie nach der Wiederherstellung den fehlgeschlagenen Schritt auf Staging und beheben Sie ihn vor einem erneuten Produktivversuch.

Entscheiden, wer die Migration ausführen soll

Wählen Sie anhand der Komplexität des tatsächlichen Shops, Ihrer Wiederherstellungsfähigkeit und der Störungskosten zwischen interner Arbeit und Spezialisten. Verlangen Sie vom Entwickler ein schriftliches Inventar, eine Daten-/URL-Zuordnung, einen erprobten Weg, Abnahmetests, Rücksetzungsplan und eine Monitoringübergabe. Begründen Sie Angebote und Ausfallzeitschätzungen mit diesem Umfang statt mit allgemeinen Marktpreisspannen.

Dokumentieren Sie bei der Übergabe die neuen Versionen, die Laufzeit, Themes, geänderte Einstellungen, die Verantwortung für Zugangsdaten, Aufgaben, Integrations-URLs und ihre Verantwortlichen, bekannte Einschränkungen, die Schritte zur Backup-Wiederherstellung und die Supportzuständigkeit. Bestätigen Sie, dass die Debugausgabe im Produktivsystem ausgeschaltet ist und temporäre Werkzeuge und Zugänge entfernt sind.