Stats Table Guard Pro

Stats Table Guard Pro – Nettoyage sûr des statistiques PrestaShop basé sur la rétention

Statut d’achat : l’achat de Stats Table Guard Pro n’est pas encore activé. Cette page décrit son workflow de nettoyage. Commencez par le scanner gratuit Stats Table Guard Lite pour inspecter vos tables de statistiques.

Stats Table Guard Pro inclut le même scanner en lecture seule que Lite et ajoute un workflow explicite de nettoyage des statistiques historiques de connexion. Il est destiné aux boutiques qui veulent garder sous contrôle les anciennes données de trafic sans nettoyage large ou automatique de la base.

Prévisualisez avant toute suppression

Le nettoyage ne démarre jamais au chargement de la page et l’enregistrement des paramètres ne déclenche aucune suppression. Un administrateur doit d’abord générer une prévisualisation, puis démarrer explicitement l’opération.

Le périmètre du nettoyage est volontairement limité

Pro nettoie uniquement les lignes historiques de connections_page, connections_source et connections. Les lignes enfants sont supprimées avant les lignes parentes.

Le nettoyage ne cible pas les clients, commandes, paniers, produits, visiteurs, statistiques de pages ni des tables arbitraires de la base.

Nettoyage basé sur la rétention

Choisissez le nombre de jours de statistiques de connexion à conserver. La période par défaut est de 180 jours, avec des préréglages de 30, 90, 180 et 365 jours ainsi qu’une valeur personnalisée.

Suppression transactionnelle par lots

Le nettoyage s’exécute par lots configurables de 100 à 5000 lignes, avec 1000 par défaut. Chaque lot utilise une transaction afin qu’un lot en échec puisse arrêter proprement l’opération au lieu de poursuivre silencieusement une opération partielle.

Contrôles de sécurité avant les actions destructives

• Le nettoyage exige les tables et colonnes de statistiques PrestaShop attendues.
• Les tables concernées doivent être vérifiables comme InnoDB avant l’activation des actions destructives.
• La date limite est validée comme date-heure réelle et comparée à la limite de rétention configurée.
• Les endpoints AJAX exigent POST, une autorisation Back Office, les capacités de l’édition et la validation du token administrateur / CSRF de PrestaShop.
• Un lot en échec arrête le nettoyage et les détails techniques sont écrits via PrestaShopLogger.
• Aucun TRUNCATE ni OPTIMIZE TABLE n’est utilisé.

Comprenez l’effet sur l’espace disque

La suppression de lignes historiques ne garantit pas que le fichier physique de la base deviendra immédiatement plus petit. InnoDB et la configuration du serveur déterminent si les pages libérées sont réutilisées ou si les fichiers peuvent rétrécir.

Planifier un nettoyage basé sur la rétention

Pro est destiné aux administrateurs qui doivent supprimer les anciennes statistiques de connexion après avoir examiné une prévisualisation. L’achat n’est pas encore activé.

1. Sauvegardez la base et déterminez les données historiques à conserver.
2. Choisissez une période de rétention. La valeur par défaut est de 180 jours.
3. Générez une prévisualisation et vérifiez la date limite et les lignes éligibles.
4. Démarrez explicitement le nettoyage après vérification. Les lots transactionnels exigent le schéma attendu et des tables InnoDB vérifiées ; un lot en échec arrête l’opération.
5. Examinez le résultat. Les lignes supprimées peuvent libérer des pages InnoDB sans réduire immédiatement le fichier physique.

Périmètre du nettoyage

Seules connections_page, connections_source et connections font partie du workflow destructif. Le service n’accepte pas un nom de table arbitraire.

Compatibilité

• Conçu pour PrestaShop 8.1.x et 9.x.
• Prend en charge les versions de PHP officiellement supportées.
• Prend en charge MySQL et MariaDB.
• N’utilise aucun override du cœur de PrestaShop.

Questions fréquentes

Le nettoyage peut-il démarrer automatiquement à l’ouverture ?

Non. Il exige une prévisualisation et une action explicite Démarrer le nettoyage.

Pro peut-il supprimer commandes, clients ou produits ?

Non. Le périmètre est strictement limité aux trois tables listées ci-dessus.

Supprimer des lignes réduit-il immédiatement le fichier de base ?

Pas nécessairement. InnoDB peut réutiliser les pages libérées sans réduire le fichier physique.

Que se passe-t-il si le moteur de stockage ne peut pas être vérifié ?

Le chemin destructif est bloqué par sécurité. L’analyse peut continuer en lecture seule réduite.

Puis-je passer de Lite à Pro sans second module ?

Oui. Lite et Pro utilisent le même répertoire technique et la même identité de module.