PrestaShop-Module entfernen, ohne benötigte Daten zu verlieren
Deinstallieren Sie PrestaShop-Module in richtiger Reihenfolge. Prüfen Sie Daten, Overrides, Zeitpläne, Endpunkte und externe Integrationen vor dem Löschen.
Deinstallieren Sie ein Modul vor dem Löschen seiner Dateien und prüfen Sie zuerst seine weiteren Abhängigkeiten. Deaktivierung, Deinstallation und Dateilöschung wirken sich unterschiedlich auf Hooks, Daten, geplante Aufgaben und externe Dienste aus.
So würden wir vorgehen
Wir würden einen begrenzten Fehler in einem benötigten Modul beheben, bevor wir es stilllegen. Die Entscheidung hängt von Ihrem bestehenden Shop ab: seinen Modulen, Integrationen, Theme, historischen Daten, Märkten und den Mitarbeitern, die seine Ausgabe nutzen.
Prüfen Sie den Wirkungsbereich auf einer Staging-Kopie mit Ihrem Theme, Ihrer PHP-Version, den anderen Modulen, Caches und der Multistore-Konfiguration. Trennen Sie die Kopie von echten E-Mails, Zahlungen, Exporten und anderen produktiven Integrationen. Verwenden Sie Testkonten oder sperren Sie Aufrufe, die externe Live-Daten ändern könnten, bevor Sie die Deinstallation erproben. Testen Sie dort Entfernungsreihenfolge und Wiederherstellung. Vereinbaren Sie anschließend ein Änderungsfenster im Live-Shop und die Zuständigkeit für die Ergebniskontrolle. Eine erfolgreiche Installation in einem sauberen Testshop deckt diese Wechselwirkungen nicht ab.
Wenn langsame Seiten den Ausschlag für die Entfernung gegeben haben, kann das PrestaShop Speed & Core Web Vitals Audit die beteiligten Anfragen und Codeabschnitte ermitteln, bevor Sie eine Korrektur wählen.
Den Wirkungsbereich eines Moduls verstehen
Ein Modul führt PHP mit den Datenbank- und Dateisystemrechten aus, die dem Shopprozess zur Verfügung stehen. Es kann Hooks registrieren, Tabellen und Konfiguration ändern, Overrides ergänzen, zugängliche Dateien bearbeiten und externe Dienste aufrufen. Seine tatsächliche Reichweite hängt von Serverberechtigungen und ausgeführtem Code ab.
Beurteilen Sie Modulqualität anhand von Verantwortlichkeit, Prüfung, Tests, Wartung, Kompatibilität und rückgängig machbaren Änderungen. KI-gestützte Entwicklung beantwortet diese Fragen nicht für Sie.
Deaktivierung, Deinstallation und Dateilöschung unterscheiden
| Aktion | Normale Wirkung | Was Sie weiterhin prüfen müssen | Wann sinnvoll |
|---|---|---|---|
| Deaktivieren | Stoppt die normale Teilnahme als aktiviertes Modul in den betroffenen Shops und ruft die Core-Behandlung registrierter Overrides auf. | Bestehende Datenänderungen, andere Shopzuordnungen, eigenständige Skripte, Serverzeitpläne und externe Dienste. | Vorübergehender Diagnoseschritt, während Sie klären, ob die Funktion noch benötigt wird. |
| Deinstallieren | Führt modulspezifische Bereinigung und den Lebenszyklus der Basisklasse aus, wenn das Modul ihn korrekt aufruft. Der Core entfernt registrierte Overrides, Hookbindungen, Hookausnahmen und Modulberechtigungen. | Aufbewahrte Tabellen und Einstellungen, vom Modul erstellte Tabs, manuell kopierte Dateien, Themeänderungen und fehlgeschlagene Bereinigungsschritte. | Eine Funktion stilllegen, sobald Abhängigkeiten und Aufbewahrungspflichten berücksichtigt sind. |
| Dateien löschen | Entfernt das Modulverzeichnis. | Vorheriges Löschen umgeht die Deinstallationsroutine und kann Registrierungsdatensätze oder defekte Verweise hinterlassen. | Eine erfolgreiche Deinstallation abschließen, sobald kein Shop den Code mehr benötigt. |
Deaktivierung ist keine Grenze für PHP-Ausführung. Ein eigenständiger Endpunkt oder extern geplantes Skript kann erreichbar bleiben, wenn weder sein Code den Modulstatus prüft noch Sie den Zugriff separat sperren.
Deinstallation ist keine Rücksetzung aller vergangenen Vorgänge. Bereits in eine Bestellung, einen Kundendatensatz oder externen Dienst geschriebene Daten benötigen eigene Behandlung.
Eine sichere Entfernungsreihenfolge einhalten
- Sichern Sie Datenbank und Dateien. Bewahren Sie das Modulpaket und seine Versionsangaben auf. Prüfen Sie, ob die Sicherung wiederherstellbar ist. Eine erneute Codeinstallation allein stellt gelöschte Daten nicht wieder her.
- Prüfen Sie aktive Bestellungen, Zahlungsrückmeldungen, Versanddienste, Steuerregeln, Marktplatzfeeds, ERP-Verbindungen und andere Module, die davon abhängen. Prüfen Sie die vom Modul bereitgestellten URLs und planen Sie Ersatzrouten oder Weiterleitungen.
- Lesen Sie die Regeln zu Aufbewahrung und Deinstallation. Exportieren Sie benötigte Datensätze und klären Sie, wie historische Rechnungen, Versanddaten oder Prüfprotokolle anschließend lesbar bleiben. Öffnen Sie ein exportiertes Muster auf Staging ohne installiertes Modul.
- Pausieren oder ersetzen Sie abhängige geplante Aufgaben und Integrationen in kontrollierter Reihenfolge. Lassen Sie laufende Arbeiten abschließen oder dokumentieren Sie deren unterstützte Wiederherstellung.
- Öffnen Sie Module > Modulmanager, suchen Sie das Modul und wählen Sie Deinstallieren.
- Bestätigen Sie den erfolgreichen Abschluss der Deinstallation. Beheben Sie Fehler, bevor Sie für die Bereinigung benötigten Code entfernen.
- Nutzen Sie, wo verfügbar, die Backoffice-Dateientfernungsoption oder entfernen Sie nach erfolgreicher Deinstallation das Modulverzeichnis.
- Leeren Sie den unterstützten Anwendungscache und testen Sie Backoffice, Storefront und betroffene Bestellabläufe.
Entfernen Sie jeweils nur ein Modul und lesen Sie das PHP-Fehlerprotokoll, bevor Sie fortfahren. In Multistore kann die Deaktivierung auf ausgewählte Shops begrenzt werden, während die Core-Deinstallation die Modulregistrierung in der gesamten Installation entfernt. Registrierte Overrides und Moduldateien werden gemeinsam genutzt. Prüfen Sie deshalb vor dem Fortfahren die Auswirkungen auf jeden Shop. Entfernen Sie keine Dateien, solange ein anderer Shop sie noch benötigt.
Wiederholen Sie die erprobte Reihenfolge mit aktuellen Live-Daten. Das Ersetzen der Produktivdatenbank durch eine ältere Staging-Datenbank kann Bestellungen und Kundenänderungen verwerfen, die seit dem Kopieren hinzugekommen sind.
Aufbewahrte Daten und verbleibende Integrationen prüfen
Datenbank- und Admindatensätze
Zahlungs-, Versand-, Support-, Marktplatz- und Prüfmodule können historische Tabellen bewusst aufbewahren. Klären Sie vor dem Löschen, weshalb die Daten gespeichert bleiben und wie lange sie benötigt werden. Löschen Sie keine gemeinsamen Pakettabellen, nur weil ein Modul sie genutzt hat.
Für eine reine Leseprüfung der Registrierungen sucht dieses Beispiel nach Cron Manager. Verwenden Sie bei der Anpassung Ihr tatsächliches Tabellenpräfix und den Namen des installierten Moduls:
SELECT m.id_module, m.name, h.name AS hook_name
FROM ps_module m
LEFT JOIN ps_hook_module hm ON hm.id_module = m.id_module
LEFT JOIN ps_hook h ON h.id_hook = hm.id_hook
WHERE m.name = 'mprcron';
SELECT id_tab, class_name, module, active
FROM ps_tab
WHERE module = 'mprcron';Diese Abfragen prüfen Registrierungen, nicht jede Tabelle, Einstellung oder Datei, die das Modul erstellt haben könnte. Identifizieren Sie diese Objekte über Installer- und Deinstallationscode des Moduls.
Overrides und Themeänderungen
Die normale Core-Lebenszyklusbehandlung entfernt korrekt registrierte Overrides. Manuell kopierte Overrides, Themeänderungen und nach fehlgeschlagener Deinstallation verbliebene Dateien benötigen separate Prüfung. Löschen Sie keine gesamte gemeinsam genutzte Override-Datei, ohne zu prüfen, welcher Code anderen Modulen gehört.
Aufgaben, Endpunkte und Dienste
Prüfen Sie Server-Cron-Einträge, Registrierungen in gemeinsamen Aufgabenplanern, Webhooks, Queue-Consumer und von externen Diensten aufgerufene Skripte. Entfernen Sie in einem gemeinsamen Aufgabenplaner nur die veraltete Aufgabe und erhalten Sie die Zeitpläne anderer Module. Widerrufen Sie ungenutzte Zugangsdaten und entfernen Sie veraltete Callbacks beim externen Dienst. Entscheiden Sie anhand der geltenden Aufbewahrungsregeln, was in externen Systemen erhalten oder gelöscht werden soll.
Ressourcen und Verhalten vor und nach der Entfernung prüfen
Ein globaler Storefront-Hook kann CSS, JavaScript oder externe Schriftarten auf Seiten laden, die die Funktion gar nicht nutzen. In einem Kundenshop wurde eine dekorative Schriftart, die nur im Einstellungsbildschirm eines Moduls verwendet wurde, auch auf Start-, Kategorie-, Produkt-, Warenkorb- und Kassenseiten geladen. Wir behielten die hilfreiche Funktion bei und korrigierten die Storefront-Registrierung. Eine nur für die Verwaltung genutzte Schriftart gehört auf die betreffende Verwaltungsseite.
Eine über hookDisplayHeader() hinzugefügte Schriftart kann beispielsweise auf Storefront-Seiten gelangen. Entfernen Sie die Registrierung ihres Stylesheets, wenn die Storefront sie nicht nutzt. Erhalten Sie andere Ressourcen und Funktionen, die derselbe Hook weiterhin benötigt. Begrenzen Sie die Ressource in hookDisplayBackOfficeHeader() auf die Konfigurationsseite oder den Controller des Moduls. Eine Prüfung des Parameters configure deckt nur den Weg über die Konfigurationsseite ab. Verwenden Sie für eigene Verwaltungsseiten daher die tatsächliche Controller-Bedingung.
- Erfassen Sie im Netzwerkbereich des Browsers Ausgangswerte für Start-, Produkt- und Kassenseiten, bei beiden Durchläufen mit deaktiviertem Browsercache. Halten Sie Anfrage-URL und Auslöser fest, nicht nur einen Geschwindigkeitswert.
- Wiederholen Sie die Messung nach Installation, Entfernung oder gezielter Korrektur unter vergleichbaren Cache- und Netzwerkbedingungen.
- Prüfen Sie neue Domains, übertragene Ressourcen und Browserfehler. Bleibt eine unerwünschte Anfrage bestehen, verfolgen Sie deren Auslöser bis zu einer Theme-Ressource oder einem zusammengefassten Cache, bevor Sie die Deinstallation verantwortlich machen.
- Schließen Sie den betroffenen Kassen- oder Kontoablauf ab und prüfen Sie, ob Hintergrundaufgaben wie vorgesehen funktionieren. Prüfen Sie nach einer gezielten Korrektur auch die Modulfunktion und ihren Einstellungsbildschirm, um sicherzustellen, dass benötigte Ressourcen weiterhin geladen werden.
Scheitert die Entfernung oder verursacht sie einen 500-Fehler, bewahren Sie die Protokolle auf und stellen Sie über Ihr getestetes Wiederherstellungsverfahren wieder her. Löschen Sie keine weiteren Dateien, bevor Sie den Fehler verstanden haben.
Fragen an Ihren Entwickler oder Ihre Agentur
- Welche Dateien, Tabellen, Einstellungen und gemeinsamen Abhängigkeiten ändern sich, und welche bleiben bewusst erhalten?
- Können Mitarbeiter ohne das Modul weiterhin eine alte Rechnung abrufen oder eine Erstattung bearbeiten?
- Welche Staging-Ergebnisse belegen, dass Kasse, Callbacks, Jobs und jeder betroffene Shop weiterhin funktionieren?
- Wer verantwortet die Umstellung im Live-Shop, die Entscheidung zum Abbruch und die Wiederherstellung, einschließlich der während der Änderung eingegangenen Bestellungen?
Häufige Fragen von Shopbetreibern
Kündigt die Entfernung eines Moduls auch sein Abonnement?
Prüfen Sie Verlängerungen und Kündigung separat im Anbieterkonto. Die Entfernung der Shop-Dateien belegt nicht, dass ein externes Abonnement oder ein Vertrag beendet wurde.
Sollte ich zum Testen der Entfernung „Zurücksetzen“ verwenden?
Behandeln Sie Zurücksetzen als potenziell destruktiv. Dabei kann Deinstallations- und Neuinstallationslogik ausgeführt werden. Prüfen Sie daher die Datenrichtlinie des installierten Moduls und erproben Sie den Vorgang, bevor Sie ihn bestätigen.
Sollte ein ungenutztes Modul unbegrenzt installiert bleiben?
Geben Sie aufbewahrtem Code einen dokumentierten Zweck, eine zuständige Person und einen Überprüfungstermin. Wenn der Zugriff auf historische Daten ihn noch benötigt, planen Sie vor der Entfernung eine Alternative. Auch deaktivierter Code braucht Wartung.