# DataFirefly Cleanup: kompletny przewodnik > 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.… - Strona: - Język: pl - Zaktualizowano: 2026-08-01 - Inne języki: [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), [de](https://www.datafirefly.com/de/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) - Indeks: ## 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 1. Pobierz plik `dfcleanup.zip` ze swojego konta DataFirefly. 2. W back office PrestaShop przejdź do **Moduły > Menedżer modułów > Wgraj moduł**. 3. Przeciągnij ZIP albo wskaż go z dysku. Instalacja tworzy tabelę historii, zakładkę administracyjną i token cron. 4. 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: 1. **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. 2. **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 (`tableExists` i `columnExists` przez `information_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 dopuszcza `LIMIT` w 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.