# « Uncaught TypeError: get_total(): Argument #1 must be of type WC_Product » après une mise à jour

> Ce message d'erreur apparaît souvent juste après la mise à jour d'une extension de tarification. Voici la démarche de diagnostic pour retrouver l'appel fautif sans deviner au hasard.

- Auteur : WordPress Développement
- Publié le : 2021-03-07
- Mis à jour le : 2021-03-07
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/uncaught-typeerror-get-total-argument-wc-product-apres-mise-a-jour/

## L’essentiel

- L'erreur signale un décalage entre le type attendu et l'objet réellement transmis
- La pile d'appels complète du log PHP pointe l'extension responsable
- Un changement de signature de méthode entre deux versions est la cause la plus fréquente

`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

> L'essentiel à retenir : L'erreur signale un décalage entre le type attendu et l'objet réellement transmis ; La pile d'appels complète du log PHP pointe l'extension responsable ; Un changement de signature de méthode entre deux versions est la cause la plus fréquente

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.

1. Identifier la version exacte installée avant l'incident, via l'historique de déploiement ou une sauvegarde
2. Comparer le changelog officiel de l'extension entre les deux versions, en cherchant les mentions de rupture de compatibilité
3. 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.