wc-ajax=update_order_review qui renvoie une erreur 500 dans la console réseau du navigateur, sans le moindre détail exploitable côté front : c’est le symptôme classique d’un calcul de frais de port ou de taxe qui échoue silencieusement côté serveur, généralement provoqué par une extension tierce accrochée au mauvais hook.
Symptôme : un blocage qui n’affiche presque rien
Le comportement typique observé côté client : le résumé de commande reste figé sur « Mise à jour… » indéfiniment, sans message d’erreur visible pour l’utilisateur, qui abandonne généralement au bout de quelques secondes en pensant à un site qui rame. Côté serveur, l’erreur PHP existe bel et bien, mais elle n’est renvoyée qu’en code HTTP 500 brut, sans corps de réponse exploitable par défaut.
Diagnostic : reproduire l’appel isolément
La première étape consiste à reproduire l’appel Ajax indépendamment du reste de la page, pour écarter tout effet de bord lié au JavaScript front :
curl -X POST https://boutique.example/?wc-ajax=update_order_review \
-H "Cookie: wp_woocommerce_session_xxx=..." \
--data "security=TOKEN&post;_data=..."Cet appel direct confirme si l’erreur vient bien du traitement serveur (réponse 500 identique) ou d’un problème purement front (dans ce cas, l’appel curl renverrait une réponse normale). Le jeton de sécurité (security) et les données de formulaire (post_data) s’obtiennent en inspectant la requête réelle via les outils de développement du navigateur avant de la rejouer.
Activer les logs détaillés pour capturer la pile d’appel
Avec WP_DEBUG et WP_DEBUG_LOG activés dans wp-config.php, l’erreur PHP complète, avec sa pile d’appel, s’écrit dans wp-content/debug.log. Sur un environnement de production, il vaut mieux activer temporairement ces constantes sur un environnement de recette identique plutôt que directement en production, pour éviter d’exposer des informations sensibles dans le journal :
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);La pile d’appel capturée pointe généralement vers un hook accroché à woocommerce_cart_calculate_fees ou woocommerce_package_rates, les deux points d’extension les plus fréquemment utilisés par des extensions tierces pour ajouter des frais ou des méthodes d’expédition personnalisées.
Localiser le hook fautif par élimination
- Désactiver un par un les plugins qui ajoutent des frais ou modifient les méthodes de livraison, en revérifiant l’appel Ajax après chaque désactivation
- Vérifier en priorité les extensions récemment mises à jour ou installées, souvent à l’origine d’une incompatibilité soudaine
- Une fois le plugin fautif identifié, inspecter son code pour repérer l’appel qui échoue, souvent une méthode appelée sur un objet
nullquand le panier se trouve dans un état inattendu (panier vide au moment du calcul, par exemple)
Un piège fréquent : le bug ne se manifeste que dans certaines conditions de panier (une combinaison précise de produits, une zone de livraison particulière), ce qui explique pourquoi il n’a pas été détecté en recette standard.
Correctif type et prévention
Une fois la ligne fautive identifiée, le correctif consiste généralement à ajouter une vérification défensive avant d’appeler une méthode sur un objet potentiellement absent, par exemple if ($package && isset($package['contents'])) avant d’accéder au contenu d’un paquet de livraison. Ajouter un test automatisé reproduisant le panier problématique évite la régression lors d’une future mise à jour de l’extension.
En résumé
Une erreur 500 sur update_order_review se diagnostique méthodiquement : reproduire l’appel isolément via curl, activer les logs détaillés sur un environnement de recette, puis éliminer les extensions une par une jusqu’à isoler le hook fautif. Cette démarche évite de désactiver des extensions au hasard en production, ce qui ne fait souvent que déplacer le problème sans le résoudre.
