Panier PrestaShop qui ne se met pas à jour : cache, JS et conflits de modules

Comment fonctionnent les mises à jour du panier dans PrestaShop

Avant de plonger dans le dépannage, il est utile de comprendre comment PrestaShop gère les opérations du panier. Lorsqu'un client clique sur « Ajouter au panier », le JavaScript côté front-end envoie une requête AJAX au serveur. Le serveur traite la requête, met à jour le panier dans la base de données et dans la session, puis renvoie une réponse JSON contenant le récapitulatif du panier mis à jour. Le JavaScript reçoit cette réponse et met à jour le bloc panier, la page produit et tous les autres éléments dépendants du panier sur la page, sans rechargement complet.

Cette approche pilotée par AJAX, introduite pleinement dans PrestaShop 1.7, a remplacé l'ancienne méthode par rechargement de page utilisée dans PrestaShop 1.6. Bien qu'elle offre une expérience d'achat beaucoup plus fluide, elle introduit également davantage de points de défaillance potentiels. Une mise à jour du panier peut échouer au niveau du JavaScript, de la requête AJAX, du traitement côté serveur ou du rendu de la réponse. Chaque point de défaillance produit des symptômes différents et nécessite des approches de diagnostic différentes.

Dans PrestaShop 1.7 et 8.x, le fichier JavaScript principal responsable des opérations du panier est core.js, qui utilise jQuery pour envoyer des requêtes AJAX au contrôleur du panier. Le contrôleur du panier traite la requête et déclenche des événements auxquels les modules peuvent se connecter via des hooks. La réponse déclenche un événement global sur la page (updateCart) que tous les composants liés au panier écoutent pour rafraîchir les données affichées.

Symptôme : cliquer sur Ajouter au panier ne fait rien

Lorsque le clic sur le bouton Ajouter au panier ne produit absolument aucune réponse — pas d'animation, pas de spinner, pas d'erreur — le problème est presque toujours une erreur JavaScript qui empêche le gestionnaire de clic de s'exécuter. L'événement de clic du bouton n'est jamais capturé, donc aucune requête AJAX n'est envoyée au serveur.

Ouvrez les outils de développement de votre navigateur (F12 ou Ctrl+Maj+I dans Chrome, Firefox et Edge) et basculez vers l'onglet Console. Rechargez la page produit et recherchez les messages d'erreur en rouge. Les erreurs courantes incluent $ is not defined ou jQuery is not defined (jQuery n'a pas réussi à se charger), Uncaught TypeError: Cannot read property of undefined (le JavaScript d'un module fait référence à quelque chose qui n'existe pas), ou Uncaught SyntaxError (un fichier JavaScript contient une erreur de syntaxe, souvent due à un module qui n'a pas été correctement minifié).

Une seule erreur JavaScript sur la page peut interrompre l'exécution de tout le JavaScript suivant, y compris la fonctionnalité principale du panier. Si un module chargé avant le JavaScript central de PrestaShop génère une erreur, l'ensemble du système de panier est cassé, même si le module n'a rien à voir avec le panier.

Pour identifier le module fautif, regardez le nom du fichier dans le message d'erreur. Il fera généralement référence à un chemin du type /modules/somemodule/views/js/somefile.js. Désactivez ce module temporairement pour confirmer qu'il est la cause, puis contactez le développeur du module pour obtenir un correctif.

Symptôme : Ajouter au panier tourne sans fin

Si le clic sur Ajouter au panier déclenche l'animation de chargement mais qu'elle tourne indéfiniment, la requête AJAX a été envoyée mais n'a soit reçu aucune réponse, soit reçu une réponse d'erreur. Basculez vers l'onglet Réseau dans les outils de développement, cliquez sur Ajouter au panier et recherchez la requête AJAX. Il s'agira généralement d'une requête POST vers une URL contenant controller=cart ou cart dans le chemin.

Cliquez sur la requête pour l'inspecter. Vérifiez la colonne Statut : un statut 200 avec un corps de réponse vide ou malformé indique une erreur PHP sur le serveur qui a été interceptée avant la sortie. Un statut 500 indique une erreur serveur non gérée. Un statut 403 peut indiquer qu'un module de sécurité ou un WAF bloque la requête. Un statut 408 ou un timeout indique que le serveur a mis trop de temps à répondre.

Si le statut est 200 mais que le corps de la réponse contient du HTML au lieu du JSON (recherchez des balises HTML dans la réponse), cela signifie que PHP a rencontré un warning ou un notice qui a été envoyé en sortie avant la réponse JSON, cassant ainsi l'analyse JSON. C'est extrêmement courant et cela est causé par des modules ou des overrides qui produisent du texte (même une ligne vide avant la balise PHP d'ouverture) pendant les hooks de traitement du panier.

Symptôme : le panier se met à jour mais affiche des données incorrectes

Parfois, le panier semble fonctionner : l'animation se joue, l'icône du panier se met à jour, mais les quantités, prix ou produits affichés sont incorrects. Il s'agit généralement d'un problème de cache où le client voit des données obsolètes au lieu des données du panier fraîchement calculées.

PrestaShop dispose de plusieurs couches de cache, chacune pouvant servir des informations de panier périmées. Comprendre et vérifier systématiquement chaque couche est essentiel pour diagnostiquer ce type de problème.

Problèmes de cache du navigateur

Le navigateur lui-même peut mettre en cache les réponses AJAX ou les fichiers JavaScript statiques. Bien que les requêtes AJAX POST ne devraient pas être mises en cache par les navigateurs, certaines configurations de cache agressives ou des service workers peuvent interférer.

Testez en ouvrant une fenêtre de navigation privée ou incognito. Si le panier fonctionne correctement en mode incognito, le problème est lié au cache du navigateur. Demandez au client de vider le cache de son navigateur, ou plus précisément, d'essayer un rafraîchissement forcé avec Ctrl+Maj+R (Windows/Linux) ou Cmd+Maj+R (Mac).

Si votre thème PrestaShop utilise un service worker pour les fonctionnalités d'application web progressive (PWA), le service worker peut intercepter et mettre en cache les requêtes AJAX. Vérifiez l'onglet Application dans les outils de développement, puis Service Workers, pour voir si un service worker est enregistré. Désenregistrez-le temporairement pour tester s'il est à l'origine du problème.

Les fichiers JavaScript statiques peuvent également être mis en cache. Si vous avez récemment mis à jour un module qui modifie le comportement du panier, le navigateur du client peut encore utiliser l'ancien fichier JavaScript. PrestaShop ajoute une chaîne de requête de version aux URL JavaScript (comme cart.js?v=1.0.0), mais cela ne fonctionne que si le module incrémente correctement son numéro de version lors de la mise à jour.

Conflits de cache Smarty

PrestaShop utilise le moteur de templates Smarty pour rendre le HTML côté serveur. Smarty possède son propre système de compilation et de mise en cache qui peut servir des sorties de templates obsolètes.

Si des templates liés au panier ont été modifiés (par une mise à jour du thème, l'installation d'un module ou une modification manuelle) mais que le cache Smarty n'a pas été vidé, l'ancien template continue d'être servi. Les templates compilés sont stockés dans /var/cache/prod/smarty/compile/ et les sorties mises en cache dans /var/cache/prod/smarty/cache/. Supprimer le contenu de ces deux répertoires force Smarty à recompiler tous les templates à partir des fichiers sources actuels.

Vous pouvez également vider le cache Smarty depuis le back office. Accédez à Paramètres avancés, puis Performances, et cliquez sur le bouton « Vider le cache ». Dans PrestaShop 8.x, vous pouvez également utiliser le bouton « Vider le cache Symfony » qui vide à la fois le cache du conteneur Symfony et le cache Smarty.

Un problème Smarty plus subtil concerne les paramètres « Forcer la compilation » et « Cache » sous Paramètres avancés, Performances, Smarty. Pendant le développement ou le débogage, réglez la Compilation des templates sur « Forcer la compilation » et le Cache sur « Non ». Cela garantit que chaque chargement de page utilise les derniers fichiers de templates. N'oubliez pas de rétablir ces paramètres à « Recompiler les templates si les fichiers ont été modifiés » et « Oui » après le débogage, car la compilation forcée impacte significativement les performances.

Paramètres CCC et leur impact

La fonctionnalité CCC (Combiner, Compresser, Cacher) de PrestaShop, accessible sous Paramètres avancés, Performances, fusionne et minifie les fichiers CSS et JavaScript pour améliorer les temps de chargement des pages. Bien que bénéfique pour les performances, le CCC peut causer des problèmes de panier de plusieurs manières.

Lorsque le CCC est activé, PrestaShop combine plusieurs fichiers JavaScript en un seul fichier mis en cache. Si le JavaScript d'un module dépend de l'ordre de chargement (il doit s'exécuter après jQuery mais avant le code d'un autre module), le processus de combinaison peut réorganiser les fichiers de manière incorrecte, provoquant l'échec du code dépendant.

Le CCC met également en cache les fichiers combinés de manière agressive. Après l'installation, la mise à jour ou la suppression d'un module, l'ancien fichier combiné peut encore être servi. La solution consiste à vider manuellement le cache CCC en allant dans Paramètres avancés, Performances, et en cliquant sur « Vider le cache » ou en supprimant les fichiers mis en cache dans /themes/your_theme/cache/.

Un problème CCC particulièrement frustrant survient lorsqu'un fichier JavaScript d'un module contient une erreur de syntaxe. Lorsque le CCC le combine avec d'autres fichiers, l'erreur de syntaxe casse l'ensemble du bundle JavaScript combiné, désactivant toutes les fonctionnalités JavaScript de la page, y compris le panier. Sans le CCC, seul le JavaScript de ce module échouerait tandis que le reste continuerait de fonctionner. Désactiver le CCC temporairement peut aider à isoler ce type de problème.

Pour tester si le CCC est à l'origine de votre problème de panier, désactivez les trois options CCC (Cache intelligent pour le CSS, Cache intelligent pour le JavaScript et Optimisation Apache) dans les paramètres de Performances. Videz tous les caches. Si le panier recommence à fonctionner, réactivez les options une par une pour identifier celle qui cause le conflit.

Problèmes de cache CDN

Si votre boutique PrestaShop utilise un CDN (réseau de diffusion de contenu) tel que Cloudflare, KeyCDN ou CloudFront, le CDN peut mettre en cache des réponses qui ne devraient pas l'être. Les CDN sont conçus pour mettre en cache le contenu statique, mais des configurations incorrectes peuvent les amener à mettre en cache des réponses AJAX dynamiques ou des pages dépendantes de la session.

Cloudflare en particulier est connu pour mettre en cache les réponses aux requêtes POST lorsque certaines règles de page ou des règles de type « tout mettre en cache » sont configurées de manière trop large. Le point de terminaison AJAX du panier renvoie des données spécifiques au client qui ne doivent jamais être mises en cache par un CDN.

Pour tester si le CDN est impliqué, contournez-le temporairement. Dans Cloudflare, vous pouvez mettre en pause le CDN ou ajouter une règle de page pour contourner le cache pour l'ensemble de votre domaine temporairement. Si le panier fonctionne correctement sans le CDN, passez en revue vos règles de mise en cache pour vous assurer que les points de terminaison AJAX et les pages dynamiques sont exclus de la mise en cache.

Pour Cloudflare spécifiquement, assurez-vous que la règle de page « Cache Everything » ne couvre pas l'ensemble de votre domaine. Si vous devez l'utiliser, ajoutez une règle de priorité supérieure qui contourne le cache pour les URL contenant controller=cart, ajax=true et le chemin du processus de commande. Vérifiez également que le « Browser Cache TTL » n'est pas réglé trop haut pour les ressources dynamiques.

Problèmes de cookies et de session

PrestaShop utilise des cookies pour maintenir la session d'achat, y compris le panier. Si les cookies ne fonctionnent pas correctement, le panier ne peut pas persister entre les requêtes. Chaque mise à jour AJAX du panier crée une nouvelle session au lieu de mettre à jour la session existante, ce qui donne un panier qui semble vide après chaque chargement de page.

Les problèmes de cookies courants incluent : le domaine du cookie est mal configuré (le cookie est défini pour www.example.com mais la requête AJAX est envoyée à example.com sans le préfixe www, ou vice versa), le chemin du cookie est incorrect, l'attribut SameSite est défini sur Strict ce qui bloque les cookies dans certains scénarios cross-origin, ou le cookie est trop volumineux et est rejeté par le navigateur (les navigateurs limitent généralement la taille des cookies à 4 Ko).

Vérifiez les cookies dans l'onglet Application des outils de développement. Recherchez le cookie de session PrestaShop (nommé PrestaShop-[hash] dans les versions récentes). Vérifiez qu'il possède le bon domaine, le bon chemin et qu'il est envoyé avec les requêtes AJAX (vérifiez l'en-tête Cookie dans l'onglet Réseau pour la requête AJAX du panier).

Sur les configurations multi-domaines ou multi-boutiques, les problèmes de cookies sont particulièrement courants. Si la boutique est accessible via http et https, ou via les versions www et non-www, le cookie peut ne pas être partagé entre ces variantes. Assurez-vous que votre boutique utilise une seule URL canonique et que toutes les autres variantes redirigent vers celle-ci.

Les problèmes de certificat SSL peuvent également empêcher les cookies de fonctionner. Si l'attribut Secure est défini sur le cookie mais que la page est chargée via HTTP (ou avec du contenu mixte), le navigateur n'enverra pas le cookie. Assurez-vous que l'ensemble de votre boutique est servi de manière cohérente en HTTPS.

Conflits de modules : processus de diagnostic

Les conflits de modules sont la cause la plus courante des problèmes de panier dans PrestaShop. Deux modules ou plus peuvent se connecter aux mêmes événements du panier et interférer entre eux, ou un seul module peut avoir un bug qui corrompt la réponse du panier.

L'approche systématique pour diagnostiquer les conflits de modules consiste à désactiver les modules par groupes. Commencez par désactiver tous les modules tiers (gardez les modules natifs de PrestaShop actifs). Si le panier fonctionne, réactivez les modules par groupes de 5. Lorsque le problème réapparaît, vous l'avez réduit à 5 modules. Désactivez ces 5 modules et réactivez-les un par un pour trouver le coupable exact.

Portez une attention particulière aux modules qui se connectent aux hooks PrestaShop suivants, car ils affectent directement le comportement du panier : actionCartSave, actionCartUpdate, displayShoppingCart, displayShoppingCartFooter, actionBeforeCartUpdateQty, actionAfterCartUpdateQty, displayHeader (les modules qui ajoutent du JavaScript ici peuvent entrer en conflit avec le JS du panier), et actionFrontControllerSetMedia.

Pour voir quels modules sont enregistrés sur les hooks liés au panier, interrogez la base de données :

SELECT h.name, m.name FROM ps_hook_module hm JOIN ps_hook h ON h.id_hook = hm.id_hook JOIN ps_module m ON m.id_module = hm.id_module WHERE h.name LIKE '%cart%' ORDER BY h.name, hm.position;

Cette requête liste tous les modules connectés aux hooks liés au panier, ainsi que leur ordre d'exécution. Les conflits surviennent souvent lorsque deux modules tentent tous les deux de modifier le total du panier ou d'appliquer des réductions de manière incompatible.

Déboguer avec les DevTools du navigateur : guide détaillé pas à pas

Les outils de développement du navigateur sont votre arme la plus puissante pour diagnostiquer les problèmes de panier. Voici un guide détaillé étape par étape pour les utiliser efficacement.

Étape 1 : Ouvrez les DevTools et allez dans l'onglet Console. Effacez tous les messages existants. Rechargez la page produit. Notez toutes les erreurs ou avertissements qui apparaissent. Ce sont des problèmes préexistants qui peuvent ou non être liés au problème de panier, mais qui doivent être documentés.

Étape 2 : Basculez vers l'onglet Réseau. Cochez la case « Conserver le journal » pour que les requêtes ne soient pas effacées lors de la navigation. Filtrez par « XHR » ou « Fetch » pour ne voir que les requêtes AJAX. Cliquez sur le bouton Ajouter au panier.

Étape 3 : Examinez la requête AJAX. Cliquez sur la requête du panier qui apparaît. Dans le sous-onglet En-têtes, vérifiez que l'URL de la requête est correcte et que le code de statut est 200. Dans le sous-onglet Données du formulaire ou Charge utile de la requête, vérifiez que l'identifiant du produit, la quantité et la combinaison d'attributs corrects sont envoyés.

Étape 4 : Vérifiez la réponse. Basculez vers le sous-onglet Réponse ou Aperçu. La réponse doit être du JSON valide. Si vous voyez du HTML mélangé, une erreur ou un avertissement PHP est émis en sortie. Si la réponse est vide, le traitement côté serveur s'est interrompu avant de générer la sortie. Si le JSON est valide mais contient des messages d'erreur, lisez-les pour obtenir des indices.

Étape 5 : Vérifiez la Console après la réponse AJAX. Les erreurs JavaScript qui se produisent lors du traitement de la réponse AJAX apparaîtront dans la Console après la fin de la requête réseau. Ces erreurs indiquent que la réponse a été reçue mais n'a pas pu être correctement traitée par le JavaScript côté front-end.

Considérations spécifiques à PrestaShop 8.x

PrestaShop 8.x utilise une architecture front-end significativement mise à jour par rapport à la version 1.7. Le JavaScript du panier a été remanié, et une partie du code précédemment dépendant de jQuery utilise désormais du JavaScript natif ou des méthodes jQuery mises à jour. Les modules écrits pour PrestaShop 1.7 qui manipulent directement le DOM du panier peuvent échouer sur la version 8.x car la structure HTML et les noms de classes CSS ont changé.

L'intégration de Symfony dans PrestaShop 8.x signifie également que le vidage du cache est plus complexe. Le cache du conteneur Symfony, situé dans /var/cache/prod/ et /var/cache/dev/, peut contenir des définitions de services compilées et des mappages de routes qui affectent la manière dont les contrôleurs du panier traitent les requêtes. Vider uniquement le cache Smarty ne suffit pas ; vous devez également vider le cache Symfony.

PrestaShop 8.x a également introduit des en-têtes Content Security Policy (CSP) plus stricts dans certaines configurations. Si votre serveur ou un module de sécurité ajoute des en-têtes CSP qui restreignent le JavaScript en ligne ou les requêtes AJAX vers des domaines spécifiques, les appels AJAX du panier peuvent être bloqués. Vérifiez la Console pour les messages de violation CSP, qui apparaissent sous forme d'erreurs rouges mentionnant « Content Security Policy ».

Problèmes côté serveur : sessions PHP et configuration

La configuration des sessions PHP peut causer des problèmes de panier difficiles à diagnostiquer car ils apparaissent de manière intermittente. Si le répertoire de stockage des sessions est plein, a des permissions incorrectes ou se trouve sur un système de fichiers ne supportant pas le verrouillage de fichiers, les sessions peuvent être perdues ou corrompues entre les requêtes.

Vérifiez la configuration de vos sessions PHP : session.save_path doit pointer vers un répertoire accessible en écriture avec suffisamment d'espace disque. session.gc_maxlifetime contrôle la durée de conservation des sessions ; si cette valeur est trop basse, les clients perdent leur panier lors de longues sessions de navigation. session.cookie_lifetime doit correspondre ou dépasser la valeur de gc_maxlifetime.

Sur les hébergements mutualisés avec de nombreux sites, le répertoire de sessions peut contenir des millions de fichiers provenant de tous les sites hébergés, ralentissant l'accès aux fichiers de session. Si votre hébergeur le prend en charge, configurez un répertoire de sessions dédié à votre site ou utilisez des sessions basées sur la base de données.

Pour les boutiques utilisant plusieurs serveurs web derrière un répartiteur de charge, les sessions doivent être partagées entre les serveurs. Si le stockage des sessions est basé sur des fichiers et local à chaque serveur, une requête suivante du client peut être dirigée vers un serveur différent qui ne possède pas sa session, aboutissant à un panier vide. Utilisez un stockage de sessions partagé tel que Redis, Memcached ou des sessions en base de données dans les environnements à répartition de charge.

Checklist de diagnostic étape par étape

Lorsqu'un client signale que le panier ne se met pas à jour, suivez cette checklist dans l'ordre :

1. Reproduisez le problème. Essayez de reproduire le problème dans une fenêtre de navigation privée en utilisant le même produit et le même navigateur que ceux signalés par le client. Si vous ne pouvez pas le reproduire, demandez au client la version de son navigateur, le type de son appareil et les étapes exactes.

2. Vérifiez la console du navigateur pour les erreurs JavaScript. Tout message d'erreur en rouge est potentiellement la cause, même s'il semble sans rapport avec le panier.

3. Vérifiez la requête réseau. Vérifiez que la requête AJAX est envoyée, renvoie un statut 200 et contient du JSON valide.

4. Videz tous les caches : cache de compilation Smarty, cache Smarty, cache Symfony, cache CCC, OPcache et cache CDN le cas échéant.

5. Désactivez le CCC. Si le panier fonctionne avec le CCC désactivé, une erreur de combinaison JavaScript en est la cause.

6. Testez avec le thème par défaut. Passez temporairement au thème classic par défaut de PrestaShop. Si le panier fonctionne avec le thème par défaut, le problème se trouve dans le JavaScript ou les templates de votre thème personnalisé.

7. Désactivez les modules tiers. Si le panier fonctionne avec tous les modules tiers désactivés, utilisez la méthode de recherche dichotomique pour identifier le module en conflit.

8. Vérifiez les logs d'erreurs PHP. Les erreurs côté serveur qui n'atteignent pas le navigateur sont enregistrées ici.

9. Vérifiez la configuration des cookies et des sessions. Vérifiez le cookie de session dans les DevTools et les paramètres de session PHP sur le serveur.

10. Testez sur un appareil et un réseau différents. Cela élimine les problèmes locaux du navigateur, les proxys réseau et les problèmes de compatibilité JavaScript spécifiques à l'appareil comme causes potentielles.