# 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… - Seite: - Sprache: de - Aktualisiert am: 2026-07-02 - Weitere Sprachen: [fr](https://www.datafirefly.com/documentation/dfcleanup/index.md), [en](https://www.datafirefly.com/en/documentation/dfcleanup/index.md), [es](https://www.datafirefly.com/es/documentation/dfcleanup/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfcleanup/index.md), [it](https://www.datafirefly.com/it/documentation/dfcleanup/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfcleanup/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfcleanup/index.md) - Index: ## Ü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. Das Modul verändert weder Ihr Theme noch PrestaShop-Core-Dateien. Es erstellt eine einzige Tabelle (die Bereinigungs-Historie) und einen Admin-Tab. ## 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. Ein in eine Bestellung umgewandelter Warenkorb wird **niemals** gelöscht: jede Abfrage prüft das Fehlen einer Bestellung über einen Join auf `ps_orders`. Ihre Bestelldaten sind unantastbar. ### 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 | Modus | Datenbankschreibvorgänge | Verwendung | | --- | --- | --- | | **Audit** | Keine | Betroffene Zeilen zählen und den Gewinn schätzen. Immer zuerst ausführen. | | **Dry-run** | Nur Historie | Die Ausführung simulieren und eine datierte Spur des Umfangs behalten. | | **Execute** | Tatsächliches Löschen | In 5.000-Zeilen-Lots löschen (konfigurierbar), mit Mikro-Pausen zwischen den Lots. | **Vor jedem Execute: sichern Sie Ihre Datenbank.** Die Bereinigung ist unumkehrbar. Empfohlener Ablauf: Audit → Dry-run → Backup → Execute → OPTIMIZE TABLE. ## 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.