PS PrestaShop Beginner

DataFirefly Cleanup: volledige gids

Installatie, zes opschoners, modi audit/dry-run/execute, crontaak en probleemoplossing van de module voor het opschonen van de PrestaShop-database.

Bijgewerkt Moduleversie 1.1.0

Presentatie

DataFirefly Cleanup is een beheermodule voor PrestaShop 8 en 9 die uw database veilig opschoont: verouderde statistieken, verlaten winkelwagens, oude logs, achterhaalde zoekopdrachten, verweesde metadata en verweesde afbeeldingen. Elke opschoner biedt drie modi (audit, dry-run en execute) en de module berekent vóór elke actie de ruimtewinst in MB.

De module wijzigt noch uw thema, noch de kernbestanden van PrestaShop. Hij maakt één tabel aan (de geschiedenis van de opschoningen) en één beheertabblad.

Installatie

  1. Download het bestand dfcleanup.zip vanuit uw DataFirefly-account.
  2. Ga in uw PrestaShop-backoffice naar Modules > Modulebeheer > Een module uploaden.
  3. Sleep het ZIP-bestand of selecteer het. De installatie maakt de geschiedenistabel, het beheertabblad en het crontoken aan.
  4. Open Geavanceerde instellingen > DataFirefly Cleanup.

Vereisten: PrestaShop 8.0+ of 9.0+, PHP 8.0+, MySQL 5.7+ of MariaDB 10.3+.

Het dashboard

Het hoofdscherm toont bovenaan drie informatieblokken:

  • Omvang van de database: de totale ruimte die uw tabellen innemen (gegevens plus indexen), berekend via information_schema.
  • Potentiële winst: de schatting van de ruimte die u terugwint wanneer alle opschoners zouden draaien.
  • Terugwinbaar percentage: de verhouding tussen die twee.

Daaronder toont de top 10 van de grootste tabellen waar uw schijfruimte werkelijk naartoe gaat. De statistiektabellen (ps_connections, ps_page_viewed) staan op een actieve webshop bijna altijd bovenaan.

De zes opschoners

Statistieken

Schoont ps_connections op (met de onderliggende tabellen connections_page en connections_source), plus ps_page_viewed, ps_referrer_cache, ps_pagenotfound en de verweesde guests. Standaard bewaartermijn: 90 dagen. Dit is doorgaans de opschoner met de grootste winst, want de statistiektabellen groeien bij elk bezoek.

Verlaten winkelwagens

Verwijdert winkelwagens zonder bijbehorende bestelling die ouder zijn dan de bewaartermijn (standaard 30 dagen), samen met de verweesde regels uit cart_product en cart_cart_rule en de vervallen winkelwagenregels.

Een winkelwagen die in een bestelling is omgezet, wordt nooit verwijderd: elke query controleert via een join op ps_orders of er geen bestelling aan hangt. Uw bestelgegevens blijven onaangeroerd.

Applicatielogs

Snoeit ps_log met een bewaartermijn die naar ernstniveau weegt: informatieve items en waarschuwingen (ernstniveau 1-2) worden na de ingestelde bewaartermijn verwijderd (standaard 30 dagen), terwijl fouten en kritieke fouten (ernstniveau 3-4) twee keer zo lang bewaard blijven.

Achterhaalde zoekopdrachten

Schoont de geschiedenis in ps_statssearch op (standaard 60 dagen) en de verweesde regels in de zoekindex (search_index, search_word) die naar verwijderde producten wijzen.

Verweesde metadata

Richt zich op regels waarvan de bovenliggende record niet meer bestaat: product_lang, product_shop, product_attribute, category_product, stock_available, specific_price, customization, soft-deleted adressen zonder bestelling, image_lang en image_shop. Hier geldt geen bewaartermijn: een wees is een wees.

Verweesde afbeeldingen

Twee onderdelen: de records in ps_image waarvan het product niet meer bestaat (altijd actief), en een optionele scan van het bestandssysteem die de map met productafbeeldingen doorloopt op zoek naar JPG-bestanden zonder record in de database. De scan is uit veiligheid geplafonneerd op 200.000 bestanden.

De drie modi

Modus Schrijven in de database Gebruik
Audit Geen De betrokken regels tellen en de winst inschatten. Altijd als eerste uitvoeren.
Dry-run Alleen de geschiedenis De uitvoering simuleren en een gedateerd spoor van het bereik bewaren.
Execute Werkelijke verwijdering Verwijderen in batches van 5.000 regels (instelbaar), met micropauzes tussen de batches.

Maak vóór elke Execute een back-up van uw database. Het opschonen is onomkeerbaar. Aanbevolen werkwijze: Audit → Dry-run → back-up → Execute → OPTIMIZE TABLE.

OPTIMIZE TABLE

Regels verwijderen geeft de ruimte niet meteen aan het systeem terug: InnoDB houdt de ruimte in het tabelbestand. Het vakje OPTIMIZE TABLE na de uitvoering herbouwt de opgeschoonde tabellen om de fysieke ruimte aan de schijf terug te geven (vereist innodb_file_per_table, standaard ingeschakeld op moderne installaties). Voer dit tijdens daluren uit: de bewerking vergrendelt elke tabel kort.

Crontaak

Met het paneel Geplande opschoning (cron) op het dashboard automatiseert u de opschoningen.

Configuratie

  • Cron activeren: globale schakelaar. Staat hij uit, dan antwoordt het endpoint met 503, ook met een geldig token.
  • Modus: audit, dry-run (standaard, zonder risico), execute, of execute met OPTIMIZE.
  • Uit te voeren opschoners: aankruisvakjes. Standaard: stats, cart, log en search. Metadata en image staan standaard uit.

URL en token

Het publieke endpoint is /module/dfcleanup/cron?token=UW_TOKEN. Het token (32 hexadecimale tekens) wordt bij de installatie gegenereerd en in constante tijd gecontroleerd. De knop Token opnieuw genereren maakt de oude URL onmiddellijk ongeldig.

Planning

Er zijn twee opties:

  1. PrestaShop-module cronjobs: is die geïnstalleerd, dan schrijft de taak zich er automatisch in (hook actionRetrieveCronJobs), gepland op 03:00 uur elke dag. Het tijdstip past u aan vanuit de configuratie van de module cronjobs.
  2. Systeemcrontab: kopieer de regel die in de beheeromgeving wordt getoond:
0 3 * * * /usr/bin/curl -s 'https://uw-winkel.com/module/dfcleanup/cron?token=XXXX' > /dev/null 2>&1

Eenmalige overrides

U kunt de modus en de opschoners voor één aanroep overschrijven, zonder de configuratie aan te raken:

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

De knop Cron nu uitvoeren draait meteen de huidige configuratie, handig om te testen zonder op de volgende geplande run te wachten.

Instellingen

  • Batchgrootte: het aantal regels dat per query wordt verwijderd (standaard 5.000, minimaal 100, maximaal 100.000). Verlaag die waarde op krappe gedeelde hosting en verhoog ze op een stevige dedicated server.
  • Bewaartermijn van de geschiedenis: hoelang de geschiedenisitems van de module bewaard blijven (standaard 180 dagen).
  • Bewaartermijn per opschoner: in dagen. 0 schakelt de tijdsfilter uit (de opschoners voor wezen negeren die instelling).

Geschiedenis

Elke actie (audit, dry-run of execute, handmatig of via cron) wordt vastgelegd: opschoner, modus, aantal betrokken regels, vrijgemaakte bytes, detail per tabel in JSON, uitvoerder (e-mailadres van de beheerder, cron of cron (manual)) en datum. De geschiedenistabel wordt automatisch opgeschoond volgens de ingestelde bewaartermijn.

Probleemoplossing

Timeout bij grote verwijderingen

De module schakelt tijdens de uitvoering de PHP-tijdslimiet uit, maar sommige hostingpartijen leggen limieten op het niveau van de webserver op. Verklein in dat geval de batchgrootte, voer opschoner per opschoner uit, of werk via de cron in CLI (curl vanuit de crontab valt niet onder de limieten van de webserver).

Het cron-endpoint antwoordt met 403

Het opgegeven token komt niet overeen. Controleer of de URL in uw crontab actueel is: een opnieuw gegenereerd token maakt de oude URL ongeldig.

Het cron-endpoint antwoordt met 503

De cron staat uit in de instellingen van de module. Zet hem aan via het paneel Geplande opschoning.

De getoonde winst verschilt van de werkelijk vrijgemaakte ruimte

De winst is een evenredige schatting (verwijderde_regels / totale_regels × tabelomvang). De ruimte die werkelijk aan de schijf wordt teruggegeven, hangt af van OPTIMIZE TABLE en van de fragmentatie. De schatting is bewust behoudend.

Technische noten

  • De module gebruikt defensieve schemadetectie (tableExists en columnExists via information_schema): hij past zich aan de verschillen tussen PS 8 en PS 9 aan en negeert ontbrekende tabellen.
  • Verwijderingen in één tabel gebeuren in batches met LIMIT; verwijderingen over meerdere tabellen (met joins) draaien in één enkele opdracht, omdat MySQL LIMIT op die syntaxis niet toestaat.
  • Het crontoken wordt vergeleken via hash_equals (in constante tijd) om bestand te zijn tegen timing-aanvallen.
  • Multistore-compatibel. Interface in FR/EN/ES/DE.
Was deze pagina nuttig?

Loopt u nog vast? Neem contact op met support