DataFirefly Cleanup — Vollständige Anleitung

Überblick

DataFirefly Cleanup ist ein Administrationsmodul für PrestaShop 8 und 9, das Ihre Datenbank sicher bereinigt: veraltete Statistiken, abgebrochene Warenkörbe, alte Logs, überholte Suchen, verwaiste Metadaten und verwaiste Bilder. Jeder Cleaner bietet drei Modi — Audit, Dry-run und Execute — und das Modul berechnet den Speichergewinn in MB vor jeder Aktion.

Installation

1. Laden Sie dfcleanup.zip aus Ihrem DataFirefly-Konto herunter.
2. Gehen Sie im PrestaShop-Backoffice zu Module > Modul-Manager > Modul hochladen.
3. Ziehen Sie das ZIP hinein oder wählen Sie es aus. Die Installation erstellt die Historie-Tabelle, den Admin-Tab und den Cron-Token.
4. Öffnen Sie Erweiterte Parameter > DataFirefly Cleanup.

Voraussetzungen: PrestaShop 8.0+ oder 9.0+, PHP 8.0+, MySQL 5.7+ oder MariaDB 10.3+.

Das Dashboard

Der Hauptbildschirm zeigt oben drei Informationsblöcke:

• Datenbankgröße — der gesamte von Ihren Tabellen belegte Platz (Daten + Indizes), berechnet über information_schema.
• Möglicher Gewinn — der geschätzte rückgewinnbare Platz, wenn alle Cleaner ausgeführt würden.
• Rückgewinnbarer Prozentsatz — das Verhältnis zwischen beiden.

Darunter zeigt die Top 10 der größten Tabellen, wohin Ihr Festplattenspeicher tatsächlich geht. Statistiktabellen (ps_connections, ps_page_viewed) stehen auf einem aktiven Shop fast immer ganz oben.

Die sechs Cleaner

Statistiken

Bereinigt ps_connections (und seine Kindtabellen connections_page und connections_source), ps_page_viewed, ps_referrer_cache, ps_pagenotfound und verwaiste Guests. Standard-Aufbewahrung: 90 Tage. Dies ist meist der Cleaner mit dem größten Gewinn — Statistiktabellen wachsen mit jedem Besuch.

Abgebrochene Warenkörbe

Entfernt Warenkörbe ohne zugehörige Bestellung, die älter als die Aufbewahrung sind (standardmäßig 30 Tage), sowie verwaiste cart_product– und cart_cart_rule-Zeilen und abgelaufene Warenkorbregeln.

Anwendungslogs

Stutzt ps_log mit nach Schweregrad gewichteter Aufbewahrung: informative Einträge und Warnungen (Schweregrad 1-2) werden nach der konfigurierten Aufbewahrung gelöscht (standardmäßig 30 Tage), während Fehler und kritische Fehler (Schweregrad 3-4) doppelt so lange aufbewahrt werden.

Veraltete Suchen

Bereinigt die ps_statssearch-Historie (standardmäßig 60 Tage) und verwaiste Suchindex-Zeilen (search_index, search_word), die auf gelöschte Produkte zeigen.

Verwaiste Metadaten

Zielt auf Zeilen, deren Elternteil nicht mehr existiert: product_lang, product_shop, product_attribute, category_product, stock_available, specific_price, customization, soft-deleted Adressen ohne Bestellung, image_lang und image_shop. Kein Aufbewahrungskonzept hier: eine Waise ist eine Waise.

Verwaiste Bilder

Zwei Teile: ps_image-Einträge, deren Produkt nicht mehr existiert (immer aktiv), und ein optionaler Filesystem-Scan, der das Produktbild-Verzeichnis nach JPG-Dateien ohne Datenbankeintrag durchsucht. Der Scan ist aus Sicherheitsgründen auf 200.000 Dateien begrenzt.

Die drei Modi

OPTIMIZE TABLE

Das Löschen von Zeilen gibt den Platz nicht sofort an das System zurück: InnoDB behält den Platz in der Tabellendatei. Die Checkbox OPTIMIZE TABLE nach der Ausführung baut die bereinigten Tabellen neu auf, um den physischen Platz an die Festplatte zurückzugeben (erfordert innodb_file_per_table, standardmäßig auf modernen Installationen aktiviert). Reservieren Sie es für Nebenzeiten: die Operation sperrt jede Tabelle kurz.

Cron-Aufgabe

Das Panel Geplante Bereinigung (Cron) des Dashboards ermöglicht die Automatisierung der Bereinigungen.

Konfiguration

• Cron aktivieren — globaler Schalter. Deaktiviert antwortet der Endpunkt 503, selbst mit gültigem Token.
• Modus — Audit, Dry-run (Standard, risikofrei), Execute, oder Execute + OPTIMIZE.
• Auszuführende Cleaner — Checkboxen. Standard: stats, cart, log, search. Metadata und image sind opt-in.

URL und Token

Der öffentliche Endpunkt ist /module/dfcleanup/cron?token=IHR_TOKEN. Der Token (32 Hex-Zeichen) wird bei der Installation generiert und in konstanter Zeit verifiziert. Die Schaltfläche Token regenerieren macht die alte URL sofort ungültig.

Planung

Zwei Optionen:

1. PrestaShop cronjobs-Modul — falls installiert, registriert sich die Aufgabe dort selbst (Hook actionRetrieveCronJobs), geplant täglich um 3:00 Uhr. Ändern Sie den Zeitplan über die Konfiguration des cronjobs-Moduls.
2. System-Crontab — kopieren Sie die im Admin angezeigte Zeile:

0 3 * * * /usr/bin/curl -s 'https://ihr-shop.com/module/dfcleanup/cron?token=XXXX' > /dev/null 2>&1

Punktuelle Übersteuerungen

Sie können Modus und Cleaner für einen einzelnen Aufruf übersteuern, ohne die Konfiguration zu ändern:

?token=XXXX&mode=audit
?token=XXXX&mode=execute&cleaners=stats,log

Die Schaltfläche Cron jetzt ausführen führt sofort die aktuelle Konfiguration aus — praktisch zum Testen, ohne auf den nächsten Tick zu warten.

Einstellungen

• Lot-Größe — pro Abfrage gelöschte Zeilen (Standard 5.000, min 100, max 100.000). Senken Sie sie auf eingeschränktem Shared Hosting, erhöhen Sie sie auf einem starken dedizierten Server.
• Historie-Aufbewahrung — wie lange das Modul seine eigenen Historie-Einträge behält (standardmäßig 180 Tage).
• Aufbewahrung pro Cleaner — in Tagen. 0 = deaktiviert den Zeitfilter (Waisen-Cleaner ignorieren diese Einstellung).

Historie

Jede Aktion (Audit, Dry-run, Execute — manuell oder Cron) wird aufgezeichnet: Cleaner, Modus, betroffene Zeilen, befreite Bytes, Details pro Tabelle als JSON, Operator (Admin-E-Mail, cron oder cron (manual)), Datum. Die Historie-Tabelle wird automatisch gemäß der konfigurierten Aufbewahrung bereinigt.

Fehlerbehebung

Timeout bei großen Löschvorgängen

Das Modul deaktiviert das PHP-Zeitlimit während der Ausführung, aber einige Hoster erzwingen Limits auf Webserver-Ebene. In diesem Fall: Lot-Größe senken, Cleaner für Cleaner ausführen, oder den Cron via CLI nutzen (curl aus der Crontab unterliegt nicht den Webserver-Limits).

Cron-Endpunkt antwortet 403

Der übergebene Token stimmt nicht überein. Prüfen Sie, ob die URL Ihrer Crontab aktuell ist — ein regenerierter Token macht die alte URL ungültig.

Cron-Endpunkt antwortet 503

Der Cron ist in den Moduleinstellungen deaktiviert. Aktivieren Sie ihn im Panel Geplante Bereinigung.

Angezeigter Gewinn weicht vom tatsächlich befreiten Platz ab

Der Gewinn ist eine proportionale Schätzung (gelöschte_Zeilen / gesamte_Zeilen × Tabellengröße). Der tatsächlich an die Festplatte zurückgegebene Platz hängt von OPTIMIZE TABLE und der Fragmentierung ab. Die Schätzung ist bewusst konservativ.

Technische Hinweise

• Das Modul verwendet defensive Schema-Erkennung (tableExists / columnExists über information_schema): es passt sich PS 8 / PS 9 Unterschieden an und überspringt fehlende Tabellen.
• Single-Table-Löschungen werden mit LIMIT gestaffelt; Multi-Table-Löschungen (Joins) laufen als einzelne Anweisung, da MySQL LIMIT bei dieser Syntax nicht erlaubt.
• Der Cron-Token wird über hash_equals (konstante Zeit) verglichen, um Timing-Angriffen standzuhalten.
• Multi-Shop-kompatibel. Oberfläche in FR/EN/ES/DE.