Ist es sicher, alte deaktivierte Module aus dem Back Office zu löschen?

Frage veröffentlicht 2540 Aufrufe

Grundsätzlich ja, aber zuerst deinstallieren, nicht nur den Ordner löschen. Ein Modul zu deaktivieren schaltet es nur aus; seine Datenbanktabellen, Hooks und Konfigurationszeilen bleiben zurück. Die richtige Reihenfolge ist:

PrestaShop-Backoffice, Modules > Module Manager, Liste deaktivierter Module mit sichtbarem Breadcrumb.
Prüfen Sie deaktivierte Module im Module Manager, bevor Sie Dateien löschen, die Sie später noch benötigen könnten.

Der normale Weg ist Modules > Module Manager, dann nach dem Modul suchen, das Aktionsmenü öffnen und Uninstall wählen. Nach der Deinstallation kann PrestaShop den Modulordner entfernen, oder Sie löschen den Ordner aus modules/modulename/, sobald die Deinstallation sauber abgeschlossen wurde.

Einige Module behalten nach der Deinstallation absichtlich historische Daten, besonders Zahlungs-, Bestell-, Versand-, Support-, Marketplace- und Audit-Module. Das ist nicht immer eine schlechte Deinstallationsroutine: Rechnungen, Bestellreferenzen, Validierungsprotokolle oder Lizenzhistorien müssen möglicherweise auch dann lesbar bleiben, wenn das Modul deaktiviert ist.

  1. Sichern Sie zuerst Datenbank und Dateien, damit eine schlechte Bereinigung reversibel ist.
  2. Klicken Sie im Back Office beim Modul auf Uninstall. Das führt die eigene Uninstall-Routine des Moduls aus, die seine Daten entfernen oder historische Datensätze beibehalten kann.
  3. Löschen Sie anschließend den Modulordner. Das Back Office kann das nach der Deinstallation für Sie erledigen.

Überspringen Sie die Deinstallation und löschen direkt den Ordner, bleiben verwaiste Tabellen und Hook-Datensätze in der Datenbank. Hilfe bei weißen Seiten und Fehler 500 finden Sie in unserem PrestaShop troubleshooting guide (Leitfaden zur Fehlerbehebung).

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 = 'modulename';

SELECT id_tab, class_name, module, active
FROM ps_tab
WHERE module = 'modulename' OR class_name LIKE '%ModuleName%';

In zwei Fällen sollten Sie pausieren: Wenn das Modul Zahlung, Versand, Steuern, Marketplace oder ERP-Integration bereitgestellt hat, bestätigen Sie zuerst, dass keine aktiven Bestellungen, Versanddienste, Webhooks oder Cronjobs noch davon abhängen; und wenn das Modul custom ist, prüfen Sie seine Uninstall-Routine, weil manche Module historische Tabellen aus Audit-Gründen absichtlich behalten. Eine gute Bereinigung ist, ein Modul nach dem anderen zu deinstallieren, das Back Office neu zu laden, das Front Office zu öffnen und das PHP-Error-Log zu prüfen, bevor Sie fortfahren.

Der Modulquellcode erklärt meist, warum der Back-Office-Uninstall-Schritt wichtig ist. Gut gebaute Module entfernen Tabs, Konfiguration, Hooks und manchmal benutzerdefinierte Admin-Präferenzen in ihrer uninstall()-Methode. Nur den Ordner zu löschen überspringt diese Bereinigung und kann kaputte Menüeinträge, tote Hooks oder Datenbanktabellen zurücklassen, die die Fehlersuche bei späteren Upgrades erschweren.

War diese Antwort hilfreich?

Noch Fragen?

Sie finden nicht, wonach Sie suchen? Senden Sie uns Ihre Frage und wir melden uns bei Ihnen.

Lade ...
Nach oben