DataFirefly Cleanup — Guide complet
Installation, six nettoyeurs, modes audit/dry-run/execute, tâche cron et dépannage du module de nettoyage de base PrestaShop.
Présentation
DataFirefly Cleanup est un module d’administration PrestaShop 8 et 9 qui nettoie votre base de données en toute sécurité : statistiques obsolètes, paniers abandonnés, logs anciens, recherches périmées, métadonnées orphelines et images orphelines. Chaque nettoyeur propose trois modes — audit, dry-run et execute — et le module calcule le gain d’espace en MB avant toute action.
Le module ne modifie ni votre thème ni les fichiers du cœur PrestaShop. Il crée une seule table (l’historique des nettoyages) et un onglet d’administration.
Installation
- Téléchargez le fichier
dfcleanup.zipdepuis votre compte DataFirefly. - Dans votre back-office PrestaShop, allez dans Modules > Gestionnaire de modules > Téléverser un module.
- Glissez le ZIP ou sélectionnez-le. L’installation crée la table d’historique, l’onglet admin et le jeton cron.
- Ouvrez Paramètres avancés > DataFirefly Cleanup.
Prérequis : PrestaShop 8.0+ ou 9.0+, PHP 8.0+, MySQL 5.7+ ou MariaDB 10.3+.
Le tableau de bord
L’écran principal affiche trois blocs d’information en tête :
- Taille de la base — l’espace total occupé par vos tables (données + index), calculé via
information_schema. - Gain potentiel — l’estimation de l’espace récupérable si tous les nettoyeurs étaient exécutés.
- Pourcentage récupérable — le ratio entre les deux.
En dessous, le top 10 des plus grosses tables vous montre où part réellement votre espace disque. Les tables de statistiques (ps_connections, ps_page_viewed) figurent presque toujours en tête sur un store actif.
Les six nettoyeurs
Statistiques
Nettoie ps_connections (et ses tables enfants connections_page et connections_source), ps_page_viewed, ps_referrer_cache, ps_pagenotfound et les guests orphelins. Rétention par défaut : 90 jours. C’est généralement le nettoyeur au plus fort gain — les tables de stats croissent à chaque visite.
Paniers abandonnés
Supprime les paniers sans commande associée plus anciens que la rétention (30 jours par défaut), ainsi que les lignes orphelines de cart_product et cart_cart_rule, et les règles panier expirées.
Un panier converti en commande n’est jamais supprimé : chaque requête vérifie l’absence de commande via une jointure sur ps_orders. Vos données de commande sont intouchables.
Logs application
Élague ps_log avec une rétention pondérée par sévérité : les entrées informatives et les avertissements (sévérité 1-2) sont supprimés après la rétention configurée (30 jours par défaut), tandis que les erreurs et erreurs critiques (sévérité 3-4) sont conservées deux fois plus longtemps.
Recherches obsolètes
Nettoie l’historique ps_statssearch (60 jours par défaut) et les lignes orphelines de l’index de recherche (search_index, search_word) pointant vers des produits supprimés.
Métadonnées orphelines
Cible les lignes dont le parent n’existe plus : product_lang, product_shop, product_attribute, category_product, stock_available, specific_price, customization, adresses soft-deleted sans commande, image_lang et image_shop. Pas de notion de rétention ici : un orphelin est un orphelin.
Images orphelines
Deux volets : les entrées ps_image dont le produit n’existe plus (toujours actif), et un scan du système de fichiers optionnel qui parcourt le dossier des images produits à la recherche de fichiers JPG sans entrée en base. Le scan est plafonné à 200 000 fichiers par sécurité.
Les trois modes
| Mode | Écriture en base | Usage |
|---|---|---|
| Audit | Aucune | Compter les lignes concernées et estimer le gain. À lancer en premier, toujours. |
| Dry-run | Historique uniquement | Simuler l’exécution et garder une trace datée du périmètre. |
| Execute | Suppression réelle | Supprimer par lots de 5 000 lignes (configurable), avec micro-pauses entre lots. |
Avant tout Execute : sauvegardez votre base. Le nettoyage est irréversible. Workflow recommandé : Audit → Dry-run → Backup → Execute → OPTIMIZE TABLE.
OPTIMIZE TABLE
Supprimer des lignes ne rend pas immédiatement l’espace au système : InnoDB conserve l’espace dans le fichier de table. La case OPTIMIZE TABLE après exécution reconstruit les tables nettoyées pour restituer l’espace physique au disque (nécessite innodb_file_per_table, activé par défaut sur les installations modernes). À réserver aux heures creuses : l’opération verrouille brièvement chaque table.
Tâche cron
Le panneau Nettoyage planifié (cron) du dashboard vous permet d’automatiser les nettoyages.
Configuration
- Activer le cron — interrupteur global. Désactivé, l’endpoint répond 503 même avec un jeton valide.
- Mode — audit, dry-run (défaut, sans risque), execute, ou execute + OPTIMIZE.
- Nettoyeurs à exécuter — cases à cocher. Par défaut : stats, cart, log, search. Metadata et image sont opt-in.
URL et jeton
L’endpoint public est /module/dfcleanup/cron?token=VOTRE_JETON. Le jeton (32 caractères hexadécimaux) est généré à l’installation et vérifié en temps constant. Le bouton Régénérer le jeton invalide immédiatement l’ancienne URL.
Planification
Deux options :
- Module cronjobs PrestaShop — si installé, la tâche s’y inscrit automatiquement (hook
actionRetrieveCronJobs), planifiée à 3h00 chaque jour. Modifiez l’horaire depuis la configuration du module cronjobs. - Crontab système — copiez la ligne affichée dans l’admin :
0 3 * * * /usr/bin/curl -s 'https://votre-boutique.com/module/dfcleanup/cron?token=XXXX' > /dev/null 2>&1Surcharges ponctuelles
Vous pouvez surcharger le mode et les nettoyeurs pour un appel donné, sans toucher à la configuration :
?token=XXXX&mode=audit
?token=XXXX&mode=execute&cleaners=stats,logLe bouton Lancer le cron maintenant exécute immédiatement la configuration courante — pratique pour tester sans attendre la prochaine échéance.
Réglages
- Taille de lot — nombre de lignes supprimées par requête (défaut 5 000, min 100, max 100 000). Baissez sur un mutualisé contraint, montez sur un serveur dédié costaud.
- Rétention de l’historique — durée de conservation des entrées d’historique du module (180 jours par défaut).
- Rétention par nettoyeur — en jours. 0 = désactive le filtre temporel (les nettoyeurs d’orphelins ignorent ce réglage).
Historique
Chaque action (audit, dry-run, execute — manuelle ou cron) est consignée : nettoyeur, mode, lignes affectées, octets libérés, détail par table en JSON, opérateur (email admin, cron ou cron (manual)), date. La table d’historique est purgée automatiquement selon la rétention configurée.
Dépannage
Timeout sur les grosses suppressions
Le module désactive la limite de temps PHP pendant l’exécution, mais certains hébergeurs imposent des limites au niveau du serveur web. Dans ce cas, réduisez la taille de lot, exécutez cleaner par cleaner, ou passez par le cron en CLI (curl depuis crontab n’est pas soumis aux limites du serveur web).
L’endpoint cron répond 403
Le jeton fourni ne correspond pas. Vérifiez que l’URL de votre crontab est à jour — un jeton régénéré invalide l’ancienne URL.
L’endpoint cron répond 503
Le cron est désactivé dans les réglages du module. Activez-le depuis le panneau Nettoyage planifié.
Le gain affiché diffère de l’espace réellement libéré
Le gain est une estimation proportionnelle (lignes_supprimées / lignes_totales × taille_table). L’espace réel restitué au disque dépend d’OPTIMIZE TABLE et de la fragmentation. L’estimation est volontairement conservatrice.
Notes techniques
- Le module utilise une détection de schéma défensive (
tableExists/columnExistsviainformation_schema) : il s’adapte aux différences PS 8 / PS 9 et ignore les tables absentes. - Les suppressions single-table sont batchées avec
LIMIT; les suppressions multi-table (jointures) s’exécutent en un seul ordre, MySQL n’autorisant pasLIMITsur cette syntaxe. - Le jeton cron est comparé via
hash_equals(temps constant) pour résister aux attaques par chronométrage. - Compatible multiboutique. Interface en FR/EN/ES/DE.