Uncaught TypeError: get_total(): Argument #1 ($product) must be of type WC_Product, null given : ce message apparaît dans les journaux PHP juste après la montée de version d’une extension de tarification, et casse immédiatement le calcul du total sur certaines commandes seulement, ce qui rend le problème d’autant plus difficile à reproduire à la main.
Voici la démarche de diagnostic que nous suivons systématiquement face à ce type d’erreur de typage après une mise à jour, sans nous limiter aux erreurs de base de données qui suivent une logique différente.
Symptôme : une erreur de type, pas une erreur logique
Une TypeError en PHP 8 signale que la déclaration de type stricte d’une méthode n’est pas respectée par l’appelant : ici, une fonction qui attend un objet WC_Product reçoit null. Ce n’est pas une erreur de calcul, mais un décalage entre ce qu’une méthode annonce accepter et ce qu’on lui transmet réellement. Ce type d’erreur est devenu plus visible depuis le typage strict des paramètres introduit progressivement dans le cœur WooCommerce, qui remplace peu à peu les vérifications implicites par des déclarations de type explicites dans les signatures de méthode.
Diagnostic : remonter la pile d’appels complète
La première étape consiste à activer le mode débogage complet de WordPress pour obtenir la trace entière, pas seulement le message d’erreur :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Le fichier wp-content/debug.log contient alors la pile d’appels complète, avec le fichier et la ligne exacte de chaque appel intermédiaire. Dans la quasi-totalité des cas rencontrés, la ligne la plus haute de la pile qui appartient à une extension tierce, et non au cœur WooCommerce, désigne l’origine réelle du problème : c’est presque toujours cette extension qui a appelé get_total() avec un objet produit non encore chargé, souvent parce qu’un identifiant de produit invalide ou supprimé a été transmis en amont.
Vérifier le changelog de l’extension mise à jour
Une fois l’extension fautive identifiée dans la trace, l’étape suivante consiste à comparer sa version installée avant et après la mise à jour. La cause la plus fréquente est un changement de signature de méthode dans une classe dont l’extension héritait ou qu’elle appelait directement : une méthode qui acceptait auparavant un identifiant numérique de produit exige désormais un objet WC_Product complet, et l’extension tierce n’a pas été mise à jour en conséquence.
- Identifier la version exacte installée avant l’incident, via l’historique de déploiement ou une sauvegarde
- Comparer le changelog officiel de l’extension entre les deux versions, en cherchant les mentions de rupture de compatibilité
- Reproduire l’appel fautif isolément dans un environnement de recette, avec le produit exact impliqué
Corriger sans se contenter d’un contournement fragile
La tentation immédiate consiste à ajouter une vérification défensive avant l’appel, du type if ( $product instanceof WC_Product ). C’est une bonne pratique en soi, mais elle masque le symptôme sans traiter la cause : il faut aussi comprendre pourquoi wc_get_product() a renvoyé false en amont, ce qui arrive typiquement quand un identifiant de produit fait référence à un post supprimé ou à une variation orpheline après une opération de nettoyage du catalogue.
Notre réflexe sur ce type d’erreur : ne jamais corriger uniquement le point d’échec visible, toujours remonter jusqu’à la fonction qui a produit l’objet manquant, faute de quoi le même symptôme réapparaît ailleurs quelques semaines plus tard.
Prévention pour la suite
Un environnement de recette qui reproduit fidèlement le catalogue de production, avec ses éventuelles incohérences de données, reste la meilleure protection contre ce genre d’incident : une mise à jour d’extension testée uniquement sur un catalogue de démonstration propre ne révèle jamais ces cas limites avec des produits partiellement supprimés ou mal migrés.
Un dernier réflexe utile consiste à figer temporairement la version de l’extension incriminée dans le gestionnaire de dépendances du projet, le temps d’appliquer le correctif, plutôt que de laisser une mise à jour automatique réintroduire la même erreur sur un autre environnement quelques jours plus tard.
