# « Call to a member function get_id() on null » : une commande fait planter le compte

> Un client ouvre son espace « Mes commandes » et obtient une page blanche. En cause : une commande incomplète que WooCommerce ne sait pas charger proprement.

- Auteur : WordPress Développement
- Publié le : 2022-03-15
- Mis à jour le : 2022-03-15
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/fatal-error-get-id-null-commande-woocommerce/

## L’essentiel

- Une commande à ID invalide plante l'espace client
- wc_get_order() peut renvoyer false
- Toujours vérifier l'objet avant d'appeler ses méthodes

« Fatal error: Uncaught Error: Call to a member function get_id() on null » : ce message apparaît dans les journaux PHP au moment précis où un client clique sur l'onglet « Commandes » de son compte, quelques secondes après avoir abandonné un paiement resté en suspens. La page reste blanche, le support reçoit un ticket, et le développeur qui ouvre les logs découvre une pile d'appels qui pointe vers un template d'espace client parfaitement banal.

Ce genre d'erreur est trompeur parce qu'elle ne se produit jamais en boutique de test avec des données propres. Il faut une commande dans un état particulier — orpheline, partiellement créée, ou associée à un identifiant qui n'existe plus dans `wp_posts` — pour la déclencher. Une fois qu'on comprend le mécanisme, le correctif prend cinq minutes ; le repérer en prend souvent bien plus.

## Symptôme : une page blanche sur l'historique des commandes

Le rapport client est presque toujours le même : « je clique sur mon historique et ça plante ». Le code HTTP renvoyé est un 500, et le journal PHP contient une trace qui remonte à une fonction de template appelant `$order->get_id()`, `$order->get_status()` ou une méthode similaire sur une variable qui vaut `null`.

Dans la majorité des cas rencontrés sur des boutiques en production, le déclencheur est une commande créée par une passerelle de paiement externe (redirection vers une banque, webhook en retard) qui n'a jamais atteint l'état `pending` correctement, ou qui a été supprimée manuellement depuis l'administration sans que les métadonnées associées au client aient été nettoyées.

## Diagnostic : remonter jusqu'à l'appel fautif

La fonction [wc_get_order()](https://developer.wordpress.org/reference/) est au cœur du problème. Elle est censée renvoyer un objet `WC_Order`, mais dès que l'identifiant passé en argument ne correspond à aucune commande valide, elle renvoie `false` — et non une exception. Tout code qui enchaîne un appel de méthode juste après, sans contrôle, provoque la fatale.

```
$order = wc_get_order( $order_id );
// Si $order_id est invalide ou supprimé, $order vaut false ici.
echo $order->get_id(); // Fatal error: Call to a member function get_id() on null/false
```

> L'essentiel à retenir : Une commande à ID invalide plante l'espace client ; wc_get_order() peut renvoyer false ; Toujours vérifier l'objet avant d'appeler ses méthodes

Pour localiser la source exacte, il est utile d'activer `WP_DEBUG_LOG` et de regarder la ligne précise indiquée dans `wp-content/debug.log`. Sur les boutiques qui utilisent un thème enfant avec des templates de compte client surchargés (typiquement `woocommerce/myaccount/orders.php` ou `view-order.php`), c'est presque toujours là que se cache l'appel non protégé.

### Repérer les commandes orphelines

Une requête simple permet de confirmer l'hypothèse : chercher les entrées de la table de métadonnées client qui référencent un identifiant de commande absent de la table des commandes (ou des `wp_posts` de type `shop_order` si le stockage historique est encore actif). Une poignée de lignes suffit généralement à expliquer plusieurs semaines de tickets sporadiques.

## Le correctif : vérifier avant d'appeler

Le correctif est toujours le même principe : ne jamais supposer que `wc_get_order()` a réussi.

```
$order = wc_get_order( $order_id );

if ( ! $order instanceof WC_Order ) {
    // Commande introuvable : on affiche un message plutôt que de planter.
    echo '<p>Cette commande n'est plus disponible.</p>';
    return;
}

echo $order->get_id();
```

Le test `instanceof WC_Order` est préférable à un simple `if ( $order )` car il couvre aussi le cas où une extension tierce renverrait un objet inattendu. Si le template modifié appartient à un thème enfant, il vaut mieux comparer sa version avec celle du thème parent WooCommerce le plus proche pour vérifier qu'aucune autre garde n'a été supprimée par erreur lors de la personnalisation.

## Prévention : verrouiller le cycle de vie des commandes

Trois réflexes limitent fortement la récurrence de ce type d'incident :

- Ne jamais supprimer une commande manuellement depuis la base sans passer par `wc_delete_shop_order()` ou l'interface d'administration, qui nettoient les métadonnées associées.
- Surveiller le hook `woocommerce_order_status_pending` et journaliser les commandes qui restent bloquées plus de quelques heures dans cet état.
- Ajouter un test automatisé qui charge la page « Mes commandes » avec un jeu de données incluant volontairement un identifiant invalide.

> Sur chaque template d'espace client surchargé, la première ligne après `wc_get_order()` devrait être un test de validité. C'est un réflexe qui coûte deux secondes à écrire et qui évite des heures de support.

## Ce qu'il faut retenir

Cette fatale n'a rien d'exotique : elle sanctionne simplement une hypothèse implicite — « la commande existe forcément » — qui finit toujours par être fausse un jour, sur une boutique suffisamment fréquentée. Le correctif tient en une condition, mais encore faut-il l'avoir posée avant que le client ne tombe sur la page blanche plutôt qu'après.