PrestaShop, taille excessive de la table layered_filter_block

La table PREFIX_layered_filter_block est le cache de requêtes du module Recherche à facettes (ps_facetedsearch). Utilisez le préfixe réel de l'installation : ce n'est pas toujours ps_.

Avant de vider, vérifiez dans phpMyAdmin la taille de chaque table et mesurez son évolution. Les clés de cache dépendent des requêtes, des filtres et des contextes de boutique, de langue, de devise et de pays réellement demandés ; la taille du catalogue ne prouve pas à elle seule l'origine de la croissance.

Le cache a été introduit dans ps_facetedsearch 3.x, et non dans une version précise du noyau de PrestaShop. Les taux de croissance publiés correspondent à des cas particuliers et ne doivent pas servir de valeur attendue pour toutes les boutiques.

Mise à jour de sécurité : ps_facetedsearch 3.0.0 à 4.0.3 est concerné par GHSA-m5f5-28qr-9g9r. Mettez à jour vers la 4.0.4 ou une version ultérieure avant de vider ou d'automatiser le cache. Si la boutique a fait tourner une version concernée, conservez les journaux et demandez une vérification d'intégrité ; vider la table ne prouve pas que l'installation est saine.

Vider le cache mesuré

Dans Modules > Gestionnaire de modules > Recherche à facettes > Configurer, utilisez Clear cache. Cette action vide PREFIX_layered_filter_block.

PREFIX_layered_price_index est un index distinct. Ne le reconstruisez que s'il est incomplet ou obsolète, et dans une fenêtre de maintenance ; vider le cache des blocs n'oblige pas à lui seul à régénérer les index. Avec InnoDB, réduire la taille logique ne garantit pas non plus que le fichier physique du tablespace diminue.

Validez les filtres, les prix, les langues et les devises après le nettoyage. Mesurez de nouveau la table pour confirmer que c'était bien celle qui grossissait.

N'automatiser que si elle grossit de nouveau

Si vous avez confirmé une croissance récurrente, copiez l'URL spécifique Flush block cache affichée dans la section cron du module. Ne copiez pas le lien AJAX du bouton et ne construisez pas l'URL manuellement. Le jeton donne accès à la tâche : traitez-le comme un identifiant et ne le publiez pas.

curl --fail --silent --show-error --max-time 300 "URL_FLUSH_BLOCK_CACHE" >> /home/usuario_cpanel/logs/prestashop-facetas.log 2>&1

Définissez la fréquence à partir des mesures et conservez le journal pendant les premières exécutions. Un cron qui échoue en silence ne maîtrise pas la croissance et ne remplace pas l'analyse du trafic ou de la configuration qui génère autant de clés.

Vérifier la tâche et la croissance

Avant de programmer l'exemple, créez un répertoire de journaux privé en dehors de la racine du site et remplacez l'URL et l'utilisateur. L'URL peut contenir un jeton visible dans la tâche programmée et dans les outils de processus ; limitez l'accès à cette configuration.

Une sortie correcte de curl ne prouve pas que le module a vidé le cache : une redirection ou une page d'erreur renvoyant un code 200 peut ressembler à une requête réussie. Examinez le corps de la réponse et comparez la taille ou le nombre de lignes de la table avant et après.

Évitez les exécutions qui se chevauchent et ajustez la fréquence et la durée de conservation du journal. Si les clés se régénèrent aussitôt, examinez les requêtes, les filtres et les contextes avant d'augmenter la fréquence de suppression ; un cache constamment vide peut augmenter le coût de la navigation.