Publié le · mis à jour le · Équipe EPNB
PrestaShop 1.6 : impossible d'ajouter un produit au panier (erreur 500, « textStatus error »)
Diagnostiquer l'erreur 500 qui bloque l'ajout au panier sur PrestaShop 1.6 et 1.7 : mode debug, requête AJAX, modules de transport et correctifs sûrs.
Sur certaines boutiques PrestaShop 1.6 (et parfois 1.7), le bouton « Ajouter au panier » ne répond plus. Le navigateur affiche au mieux le message « Impossible to add the product to the cart – textStatus error », au pire rien du tout. Dans la grande majorité des cas, la cause est une erreur 500 côté serveur pendant l’appel AJAX du panier.
Ce qui se passe quand on ajoute un produit
L’ajout au panier déclenche une requête AJAX, généralement de la forme POST /?rand=XXXXXXXX (le paramètre rand sert à contourner le cache). Côté serveur, PrestaShop crée ou met à jour le panier, recalcule les règles de prix, puis calcule les frais de livraison en appelant les modules de transport.
Si un seul de ces modules provoque une erreur PHP, la requête échoue avec un code 500, le panier n’est pas mis à jour et le message d’erreur apparaît côté navigateur.
Diagnostiquer en deux étapes
1. Lire l’erreur réelle
Activez le mode debug sur une copie de la boutique, ou très brièvement en production en dehors des heures de vente. Dans /config/defines.inc.php, remplacez :
define('_PS_MODE_DEV_', false);
par :
define('_PS_MODE_DEV_', true);
Pensez à revenir à false juste après : le mode debug affiche des chemins et des informations techniques à vos visiteurs. Les journaux PHP de l’hébergement donnent souvent la même information sans rien exposer.
2. Inspecter la requête AJAX
Dans le navigateur (F12, onglet Réseau), cherchez la requête contenant cart ou rand, vérifiez son statut (500) et lisez le contenu de la réponse. Une erreur typique ressemble à :
Fatal error: Call to a member function query() on null
Elle signale qu’un module tente d’utiliser un objet non initialisé, le plus souvent une connexion à la base de données ou à une API externe.
Le suspect numéro un : les modules de transport
Désactivez les modules de transporteurs un par un, en testant l’ajout au panier après chaque désactivation. Nous avons par exemple rencontré ce cas avec le module EnvoiMoinsCher en version 3.3.3.
Attention à un piège classique : désactiver le module ne suffit pas toujours, car le transporteur associé peut rester actif en base et continuer d’être appelé. Vérifiez dans Livraison > Transporteurs que le transporteur correspondant est bien désactivé.
Débloquer la boutique sans tout casser
- Créer un transporteur simple à tarif fixe, sans module, pour que les clients puissent commander pendant le diagnostic.
- Désactiver le transporteur fautif depuis le back-office plutôt que par une requête SQL globale. Une requête qui désactive d’un coup tous les transporteurs liés à un module, ou qui réinitialise le transporteur de tous les paniers, est rapide mais touche aussi des données que vous ne voulez pas modifier. Si vous passez par la base, ciblez un identifiant précis et faites une sauvegarde avant.
- Vider le cache : depuis Paramètres avancés > Performances, ou en supprimant le contenu de
/cache/smarty/compile/et/cache/smarty/cache/.
Les autres causes à vérifier
- Une version de PHP incompatible : PrestaShop 1.6 a été conçu pour PHP 5.6 à 7.1, et un changement de version chez l’hébergeur suffit à faire tomber un module ancien.
- Un module récemment installé ou mis à jour.
- Un override cassé après une mise à jour.
- Une API externe (transport, paiement) indisponible ou dont le format de réponse a changé.
À retenir
L’ajout au panier enchaîne des traitements complexes : livraison, règles de prix, modules. Une seule erreur PHP suffit à tout bloquer, et les modules de transport sont les premiers à vérifier. Plus largement, une boutique PrestaShop 1.6 fonctionne aujourd’hui sur des versions de PHP qui ne reçoivent plus de correctifs de sécurité : ce type de panne est souvent le signe qu’il est temps de planifier une maintenance de fond ou une migration.