DataFirefly Cleanup: kompletny przewodnik
Instalacja, sześć modułów czyszczących, tryby audit, dry-run i execute, zadanie cron oraz rozwiązywanie problemów w module czyszczenia bazy PrestaShop.
Prezentacja
DataFirefly Cleanup to moduł administracyjny do PrestaShop 8 i 9, który bezpiecznie czyści twoją bazę danych: przestarzałe statystyki, porzucone koszyki, stare logi, nieaktualne wyszukiwania, osierocone metadane i osierocone obrazy. Każdy moduł czyszczący oferuje trzy tryby, audit, dry-run i execute, a przed jakąkolwiek akcją wyliczany jest zysk miejsca w MB.
Moduł nie zmienia ani twojego szablonu, ani plików rdzenia PrestaShop. Tworzy jedną tabelę (historię czyszczeń) i jedną zakładkę administracyjną.
Instalacja
- Pobierz plik
dfcleanup.zipze swojego konta DataFirefly. - W back office PrestaShop przejdź do Moduły > Menedżer modułów > Wgraj moduł.
- Przeciągnij ZIP albo wskaż go z dysku. Instalacja tworzy tabelę historii, zakładkę administracyjną i token cron.
- Otwórz Parametry zaawansowane > DataFirefly Cleanup.
Wymagania: PrestaShop 8.0+ albo 9.0+, PHP 8.0+, MySQL 5.7+ albo MariaDB 10.3+.
Pulpit
Główny ekran pokazuje na górze trzy bloki informacyjne:
- Rozmiar bazy: całkowite miejsce zajmowane przez twoje tabele (dane plus indeksy), wyliczane przez
information_schema. - Potencjalny zysk: szacunek miejsca do odzyskania, gdyby uruchomić wszystkie moduły czyszczące.
- Procent do odzyskania: stosunek jednego do drugiego.
Poniżej top 10 największych tabel pokazuje, gdzie faktycznie ucieka twoje miejsce na dysku. W aktywnym sklepie na czele niemal zawsze stoją tabele statystyk (ps_connections, ps_page_viewed).
Sześć modułów czyszczących
Statystyki
Czyści ps_connections (wraz z tabelami potomnymi connections_page i connections_source), ps_page_viewed, ps_referrer_cache, ps_pagenotfound oraz osieroconych gości. Domyślna retencja: 90 dni. To zwykle moduł o największym zysku, bo tabele statystyk rosną przy każdej wizycie.
Porzucone koszyki
Usuwa koszyki bez powiązanego zamówienia starsze niż retencja (domyślnie 30 dni), a także osierocone wiersze w cart_product i cart_cart_rule oraz wygasłe reguły koszyka.
Koszyk przekształcony w zamówienie nigdy nie jest usuwany: każde zapytanie sprawdza brak zamówienia złączeniem z ps_orders. Twoje dane zamówień pozostają nietknięte.
Logi aplikacji
Przycina ps_log z retencją ważoną według wagi zdarzenia: wpisy informacyjne i ostrzeżenia (waga 1-2) są usuwane po skonfigurowanej retencji (domyślnie 30 dni), a błędy i błędy krytyczne (waga 3-4) są przechowywane dwa razy dłużej.
Nieaktualne wyszukiwania
Czyści historię ps_statssearch (domyślnie 60 dni) oraz osierocone wiersze indeksu wyszukiwania (search_index, search_word) wskazujące na usunięte produkty.
Osierocone metadane
Celuje w wiersze, których rodzic już nie istnieje: product_lang, product_shop, product_attribute, category_product, stock_available, specific_price, customization, adresy usunięte miękko i bez zamówienia, image_lang oraz image_shop. Nie ma tu pojęcia retencji: sierota to sierota.
Osierocone obrazy
Dwa człony: wpisy w ps_image, których produkt już nie istnieje (zawsze aktywne), oraz opcjonalne skanowanie systemu plików, które przechodzi katalog obrazów produktów w poszukiwaniu plików JPG bez wpisu w bazie. Skanowanie jest dla bezpieczeństwa ograniczone do 200 000 plików.
Trzy tryby
| Tryb | Zapis do bazy | Zastosowanie |
|---|---|---|
| Audit | Brak | Policzenie objętych wierszy i oszacowanie zysku. Zawsze uruchamiaj jako pierwszy. |
| Dry-run | Wyłącznie historia | Symulacja wykonania z datowanym śladem zakresu. |
| Execute | Rzeczywiste usunięcie | Usuwanie partiami po 5 000 wierszy (konfigurowalne), z mikroprzerwami między partiami. |
Przed każdym trybem Execute zrób kopię zapasową bazy. Czyszczenie jest nieodwracalne. Zalecany przebieg: Audit, Dry-run, kopia zapasowa, Execute, OPTIMIZE TABLE.
OPTIMIZE TABLE
Usunięcie wierszy nie oddaje od razu miejsca systemowi: InnoDB zachowuje przestrzeń w pliku tabeli. Opcja OPTIMIZE TABLE po wykonaniu przebudowuje wyczyszczone tabele, żeby zwrócić fizyczne miejsce na dysk (wymaga innodb_file_per_table, domyślnie włączonego w nowoczesnych instalacjach). Rezerwuj to na godziny o niskim ruchu, bo operacja krótko blokuje każdą tabelę.
Zadanie cron
Panel Zaplanowane czyszczenie (cron) na pulpicie pozwala zautomatyzować czyszczenia.
Konfiguracja
- Włącz cron: przełącznik globalny. Przy wyłączonym endpoint odpowiada kodem 503 nawet z poprawnym tokenem.
- Tryb: audit, dry-run (domyślny, bez ryzyka), execute albo execute plus OPTIMIZE.
- Moduły do uruchomienia: pola wyboru. Domyślnie stats, cart, log i search. Metadata i image wymagają świadomego włączenia.
URL i token
Publiczny endpoint to /module/dfcleanup/cron?token=TWOJ_TOKEN. Token (32 znaki szesnastkowe) jest generowany przy instalacji i weryfikowany w stałym czasie. Przycisk Wygeneruj token ponownie natychmiast unieważnia stary adres.
Planowanie
Dwie opcje:
- Moduł cronjobs PrestaShop: jeśli jest zainstalowany, zadanie rejestruje się w nim automatycznie (hook
actionRetrieveCronJobs), zaplanowane codziennie na 3:00. Godzinę zmienisz w konfiguracji modułu cronjobs. - Systemowy crontab: skopiuj linię wyświetloną w panelu administracyjnym:
0 3 * * * /usr/bin/curl -s 'https://twoj-sklep.pl/module/dfcleanup/cron?token=XXXX' > /dev/null 2>&1
Doraźne nadpisania
Możesz nadpisać tryb i listę modułów dla pojedynczego wywołania, bez zmiany konfiguracji:
?token=XXXX&mode=audit
?token=XXXX&mode=execute&cleaners=stats,log
Przycisk Uruchom cron teraz wykonuje bieżącą konfigurację natychmiast, co jest wygodne do testów bez czekania na kolejny termin.
Ustawienia
- Rozmiar partii: liczba wierszy usuwanych w jednym zapytaniu (domyślnie 5 000, minimum 100, maksimum 100 000). Zmniejsz na ograniczonym hostingu współdzielonym, zwiększ na mocnym serwerze dedykowanym.
- Retencja historii: czas przechowywania wpisów historii modułu (domyślnie 180 dni).
- Retencja per moduł czyszczący: w dniach. Wartość 0 wyłącza filtr czasowy (moduły czyszczące sieroty ignorują to ustawienie).
Historia
Każda akcja (audit, dry-run, execute, ręczna albo z crona) jest zapisywana: moduł czyszczący, tryb, liczba objętych wierszy, zwolnione bajty, szczegóły per tabela w JSON, operator (e-mail administratora, cron albo cron (manual)) i data. Tabela historii jest czyszczona automatycznie zgodnie ze skonfigurowaną retencją.
Rozwiązywanie problemów
Timeout przy dużych usunięciach
Moduł wyłącza limit czasu PHP na czas wykonania, ale część hostingów narzuca limity na poziomie serwera WWW. W takim wypadku zmniejsz rozmiar partii, uruchamiaj moduł po module albo przejdź na cron w CLI (curl z crontaba nie podlega limitom serwera WWW).
Endpoint cron odpowiada kodem 403
Podany token się nie zgadza. Sprawdź, czy adres w twoim crontabie jest aktualny, bo ponowne wygenerowanie tokenu unieważnia stary URL.
Endpoint cron odpowiada kodem 503
Cron jest wyłączony w ustawieniach modułu. Włącz go w panelu Zaplanowane czyszczenie.
Wyświetlony zysk różni się od faktycznie zwolnionego miejsca
Zysk jest szacunkiem proporcjonalnym (usunięte_wiersze / wszystkie_wiersze × rozmiar_tabeli). Rzeczywiste miejsce zwrócone na dysk zależy od OPTIMIZE TABLE i od fragmentacji. Szacunek jest celowo zachowawczy.
Uwagi techniczne
- Moduł stosuje defensywne wykrywanie schematu (
tableExistsicolumnExistsprzezinformation_schema): dostosowuje się do różnic między PS 8 i PS 9 oraz pomija nieobecne tabele. - Usunięcia z jednej tabeli są dzielone na partie klauzulą
LIMIT. Usunięcia wielotabelowe (ze złączeniami) wykonują się jednym poleceniem, bo MySQL nie dopuszczaLIMITw tej składni. - Token cron jest porównywany funkcją
hash_equals(stały czas), co chroni przed atakami czasowymi. - Zgodny z multisklepem. Interfejs w FR, EN, ES i DE.