PS PrestaShop Początkujący

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.

Zaktualizowano Wersja modułu 1.1.0

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.
Czy ta strona była pomocna?

Nadal utknąłeś? Napisz do wsparcia