# Erreur 500 sur wc-ajax=update_order_review : méthode de diagnostic

> La page de commande plante en silence lors du recalcul des frais de port en Ajax. Voici comment isoler le hook fautif sans tout désactiver au hasard.

- Auteur : WordPress Développement
- Publié le : 2022-02-18
- Mis à jour le : 2022-02-18
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/erreur-500-wc-ajax-update-order-review/

## L’essentiel

- Reproduire l'erreur en isolant l'appel Ajax du reste de la page
- Activer les logs détaillés pour capturer la pile d'appel
- Localiser précisément le hook fautif par élimination

`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.

> L'essentiel à retenir : Reproduire l'erreur en isolant l'appel Ajax du reste de la page ; Activer les logs détaillés pour capturer la pile d'appel ; Localiser précisément le hook fautif par élimination

## 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 `null` quand 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.