Uncaught Error: Call to a member function get_total() on bool : ce message, remonté dans les journaux d’erreur PHP, indique une chose précise et souvent mal comprise au premier regard : quelque part dans le code, une variable censée contenir un objet WC_Order contient en réalité la valeur booléenne false, et une méthode a été appelée dessus sans vérification préalable.
Symptôme : un fatal qui survient de façon imprévisible
Ce type d’erreur a la particularité de ne jamais se manifester de façon systématique. Elle apparaît lors du traitement d’un webhook différé, d’un rapport planifié exécuté la nuit, ou d’un export qui parcourt un lot d’identifiants de commande collectés plus tôt. Le point commun à ces trois cas : un identifiant de commande a été mémorisé à un instant donné, puis réutilisé plus tard, après que la commande correspondante a été supprimée entre-temps.
Diagnostic : localiser l’appel fautif
La fonction wc_get_order( $id ) constitue le point d’entrée standard pour récupérer un objet commande à partir de son identifiant. Son comportement est documenté et sans ambiguïté : si aucune commande ne correspond à l’identifiant fourni, elle renvoie false, jamais une exception, et jamais un objet vide qui accepterait silencieusement un appel de méthode.
$commande = wc_get_order( $id_commande );
$total = $commande->get_total(); // fatal si $commande vaut false
Le diagnostic consiste donc à remonter, dans la pile d’appels fournie par le message d’erreur, jusqu’au premier endroit où wc_get_order() est appelée sans que son retour ne soit vérifié avant l’appel de méthode suivant. Sur le cas traité, l’origine se trouvait dans un rapport planifié qui conservait une liste d’identifiants de commande collectée la veille, sans anticiper qu’une commande de test aurait entre-temps été supprimée manuellement par un administrateur.
Correctif : vérifier systématiquement le retour
$commande = wc_get_order( $id_commande );
if ( ! $commande instanceof WC_Order ) {
continue; // ou journaliser l'identifiant orphelin, selon le contexte
}
$total = $commande->get_total();
La vérification instanceof WC_Order plutôt qu’un simple test de vérité booléenne présente un avantage supplémentaire : elle couvre également le cas, plus rare mais réel, où wc_get_order() renverrait un objet d’un autre type selon la configuration du site, par exemple lors d’une migration en cours entre deux modes de stockage des commandes.
Prévention : ne jamais faire confiance à un identifiant mémorisé
Au-delà du correctif ponctuel, ce type d’incident pointe un problème d’architecture plus large : dès qu’un identifiant de commande est mémorisé pour un traitement différé, que ce soit dans une option, un fichier temporaire, ou une file de tâches planifiées, il faut considérer que la commande correspondante peut avoir disparu au moment du traitement effectif.
- Toujours vérifier le retour de
wc_get_order()avant tout appel de méthode, sans exception. - Pour un traitement en lot, journaliser les identifiants orphelins plutôt que de les ignorer silencieusement, afin de détecter une suppression anormale de commandes.
- Éviter de conserver des identifiants de commande sur une durée longue sans mécanisme de nettoyage : plus le délai entre collecte et traitement est long, plus le risque de commande supprimée entre-temps augmente.
Un appel à wc_get_order() sans vérification du retour est, à mes yeux, le même genre d’oubli qu’un accès à un tableau sans vérifier isset() au préalable : anodin en apparence, fatal en production dès que le contexte change.
Ce que ce correctif ne traite pas
Ce billet ne couvre pas la question de la restauration d’une commande supprimée par erreur : une fois une commande réellement effacée de la base, sans passage par la corbeille, elle reste perdue, sauf sauvegarde de base de données antérieure à la suppression. Le sujet ici se limite à éviter que cette suppression, légitime ou non, ne provoque un fatal error ailleurs dans le code.
En résumé
Ce fatal error, en apparence obscur, se résout toujours de la même façon : vérifier que wc_get_order() a bien renvoyé un objet commande avant d’appeler une méthode dessus. La vraie leçon dépasse ce correctif ponctuel : tout identifiant de commande conservé pour un traitement différé doit être traité comme potentiellement obsolète au moment de son utilisation réelle.
