PrestaShop Update fehlgeschlagen: Fehler eingrenzen und sicher wiederherstellen
Wenn ein PrestaShop Update abbricht, das Backoffice nicht mehr startet oder der Shop nach dem Update Fehler zeigt, ist der wichtigste erste Schritt nicht ein weiterer Update-Versuch. Zuerst müssen Update-Phase, Fehlermeldung und der zusammengehörige Stand von Dateien und Datenbank gesichert werden.
Dieser Leitfaden ist eine technische Erstdiagnose. Er ersetzt keine Prüfung des konkreten Shops. Führen Sie keine Wiederherstellung im Produktivsystem durch, wenn unklar ist, ob nach dem Update bereits neue Bestellungen, Kundenkonten oder Bestandsänderungen entstanden sind.
Sofortmaßnahmen nach einem fehlgeschlagenen PrestaShop Update
- Weitere Schreibvorgänge begrenzen: Verhindern Sie neue Änderungen, wenn Frontoffice oder Datenbank in einem unklaren Zwischenstand sind.
- Fehler nicht überschreiben: Starten Sie das Update nicht wiederholt, bevor Meldung, Zeitpunkt und letzte erfolgreiche Phase dokumentiert sind.
- Aktuellen Zustand sichern: Erstellen Sie eine zusätzliche Sicherung des fehlerhaften Zustands, bevor Dateien, Logs oder Datenbank erneut verändert werden.
- Ausgangsdaten festhalten: Notieren Sie Quell- und Zielversion, PHP, Datenbank, Update-Assistant-Version, Theme und zuletzt geänderte Module.
- Geschäftsauswirkung prüfen: Klären Sie, ob Bestellungen, Zahlungseingänge, E-Mails oder Schnittstellen seit Beginn des Updates weitergelaufen sind.
In welcher Phase ist das Update fehlgeschlagen?
Die offizielle Prozessbeschreibung des Update Assistant unterscheidet unter anderem Download, Entpacken, Modulvorbereitung, Dateiupdate, Datenbankupdate und Modulupdate. Die Fehlerphase entscheidet darüber, ob eine Voraussetzung korrigiert, ein Teilprozess repariert oder der vollständige vorherige Stand wiederhergestellt werden sollte.
| Fehlerphase | Typische Hinweise | Sichere nächste Prüfung |
|---|---|---|
| Vorprüfung | PHP-, Erweiterungs-, Speicher-, Rechte- oder Kompatibilitätswarnung | Voraussetzung korrigieren und Update-Pfad erneut ausschließlich im Staging testen |
| Download oder Entpacken | Netzwerkfehler, unvollständiges Archiv, fehlender Speicher oder Schreibrechte | Archiv, Speicherplatz, Berechtigungen und Integrität prüfen; Live-Zustand nicht unnötig verändern |
| Dateiupdate | Front- oder Backoffice lädt nicht, Klassen oder Dateien fehlen | Dateistand und Log sichern; prüfen, ob Datenbankänderungen bereits begonnen haben |
| Datenbankupdate | SQL-Fehler, fehlende Tabellen oder Spalten, inkonsistenter Versionsstand | Dateien und Datenbank als zusammengehöriges Paar behandeln; keine Teilwiederherstellung improvisieren |
| Modulupdate | Fehler in Modulklasse, Hook, Migration oder Abhängigkeit | Betroffenes Modul und seine Datenmigration identifizieren; Kompatibilität und Rückweg bewerten |
| Nachkontrolle | Shop startet, aber Checkout, E-Mail, Suche oder Schnittstellen sind fehlerhaft | Geschäftskritische Testfälle priorisieren und Entscheidung zwischen Korrektur und Rollback dokumentieren |
Welche Informationen werden für die Fehleranalyse benötigt?
- vollständige Fehlermeldung und Zeitpunkt,
- letzte sichtbare Update-Phase und Fortschrittsanzeige,
- Update-Assistant- und PrestaShop-Protokolle,
- Quellversion, geplante Zielversion und Update-Kanal,
- PHP-, Datenbank- und Serverversion,
- freier Speicherplatz, Dateirechte und relevante PHP-Limits,
- Liste der Module, Overrides, Core-Anpassungen und des aktiven Themes,
- vorhandene Backups mit Zeitpunkt, Umfang und geprüftem Speicherort,
- Status von Frontoffice, Backoffice, Cronjobs und Schnittstellen,
- Information, ob seit dem Update neue Geschäftsdaten entstanden sind.
Häufige technische Ursachen
- nicht erfüllte PHP- oder Serveranforderungen,
- zu wenig Speicherplatz oder zu geringe PHP-Limits,
- fehlende Schreibrechte oder abweichender Dateibesitz,
- unvollständige Downloads oder unterbrochene Prozesse,
- inkompatible beziehungsweise nicht mehr gepflegte Module,
- Core-Anpassungen und Overrides, die mit der Zielversion kollidieren,
- Theme- und Template-Anpassungen,
- fehlerhafte Datenbankmigrationen oder bereits inkonsistente Altdaten,
- Zeitüberschreitungen bei großen Datenbanken oder Dateibeständen,
- Cronjobs, Cache oder externe Prozesse, die während des Updates weiterarbeiten.
Wiederherstellen oder den Fehler korrigieren?
Eine Korrektur kann sinnvoll sein, wenn der Fehler eindeutig, reproduzierbar und auf eine noch nicht veränderte beziehungsweise kontrolliert wiederherstellbare Phase begrenzt ist. Ein Rollback ist meist die sicherere Entscheidung, wenn Dateien und Datenbank nur teilweise aktualisiert wurden, mehrere unbekannte Fehler auftreten oder geschäftskritische Funktionen nicht zuverlässig geprüft werden können.
Der Update Assistant kann eine von ihm erstellte Sicherung wiederherstellen und stellt dafür auch einen CLI-Prozess bereit. Laut offizieller PrestaShop-Dokumentation umfasst ein vollständiges Backup sowohl Shopdateien als auch die Datenbank. Eine alte Datenbank mit neuen Dateien oder umgekehrt kann zusätzliche Inkonsistenzen erzeugen.
Wichtig nach Wiedereröffnung: Sobald neue Bestellungen, Kunden oder Lagerbewegungen entstanden sind, darf ein älteres Backup nicht ohne Datenabgleich eingespielt werden. Diese neuen Geschäftsdaten müssen vor einer Rollback-Entscheidung berücksichtigt werden.
Was sollte nach einer Wiederherstellung geprüft werden?
- Frontoffice und Backoffice öffnen und Versionsstand eindeutig prüfen.
- Cache, Logs und Wartungsmodus kontrollieren.
- Produkte, Kategorien, Suche, Varianten und Preise testen.
- Warenkorb und Checkout mit wichtigen Zahlungs- und Versandarten ausführen.
- Bestellstatus, E-Mails, Rechnung und Rückerstattung prüfen.
- Cronjobs, Webhooks, ERP-, PIM- und Marktplatzprozesse testen.
- URLs, Sitemap, Canonicals, Weiterleitungen und Tracking stichprobenartig kontrollieren.
- Erst danach normalen Betrieb und automatische Prozesse vollständig freigeben.
Wie lässt sich der nächste Update-Versuch absichern?
Der nächste Versuch beginnt mit einer frischen, realistischen Staging-Kopie und einem dokumentierten Ausgangszustand. Der Update Assistant stellt Prüfungen für Systemanforderungen und Modulkompatibilität bereit. Alle Korrekturen werden zuerst dort wiederholt, anschließend folgen fachliche Testfälle und ein geplanter Livegang.
Für einen Versionswechsel von 8.x hilft die PrestaShop 8 auf 9 Checkliste. Bei PrestaShop 1.7 beschreibt der Update-Assistant-Guide für 1.7 auf 9.1 den größeren Migrationspfad.
Häufige Fragen zu fehlgeschlagenen PrestaShop Updates
Kann ich das Update einfach erneut starten? Erst wenn klar ist, in welcher Phase es abgebrochen ist und ob Dateien oder Datenbank bereits verändert wurden. Wiederholte Versuche können Logs und Ausgangszustand unübersichtlicher machen.
Reicht es, nur die Dateien zurückzukopieren? Nicht wenn bereits Datenbankänderungen durchgeführt wurden. Dateien und Datenbank müssen zu demselben geprüften Stand gehören.
Kann der Update Assistant sein Backup wiederherstellen? Der offizielle Update Assistant bietet einen Restore-Prozess für von ihm erstellte Sicherungen. Vorher muss geprüft werden, ob die Sicherung vollständig ist und ob inzwischen neue Geschäftsdaten entstanden sind.
Was, wenn kein verwendbares Backup existiert? Dann wird der aktuelle Zustand zunächst gesichert und technisch analysiert. Je nach Update-Phase kann eine Reparatur, eine Rekonstruktion aus vorhandenen Teilständen oder ein geplanter Neuaufbau erforderlich sein.
Offizielle Quellen und technische Hilfe
- Update Assistant: Prüf-, Update-, Backup- und Restore-Prozesse
- Offizielle PrestaShop Backup-Dokumentation
- Offizielle PrestaShop Update-Dokumentation
Wenn der Shop bereits in einem unklaren Zwischenstand ist, unterstützt der PrestaShop Support bei Sicherung und Fehleranalyse. Für einen neu geplanten Versionswechsel beschreibt der PrestaShop Update Service Audit, Staging, Tests, Livegang und Monitoring.