Tu connais cette sensation ? Ton site WooCommerce tourne nickel, connecté à un service externe qui gère tes stocks en automatique. Tout baigne… et puis BAM. Des écarts bizarres entre tes stocks réels et ce qui s’affiche. Le service externe te jure qu’il envoie les bonnes infos. Toi, tu viens de récupérer le site et t’as ZERO visibilité sur ce qui se passe vraiment.
Ouais, j’y suis passé récemment. J’ai récupéré un site WooCommerce en perso. Les produits sont mis à jour via un service externe. Depuis que j’ai récupéré le site, on me dit qu’il y a des soucis de stocks … La galère pour moi vu que je suis en soit le seul élément nouveau dans l’équation. Mais on ne se décourage pas, je n’ai pas beaucoup d’informations donc première step : les logs !
Je vais te montrer comment mettre en place un système de logging intelligent sur l’API REST WooCommerce avec les hooks natifs de WordPress. Ça marche pour tous les endpoints WordPress d’ailleurs. Parce que chercher à l’aveugle … c’est compliqué
Table des matières
- Le problème : quand tes stocks font n’importe quoi
- Pourquoi logger l’API REST WooCommerce
- Le hook rest_pre_dispatch : capturer les requêtes
- Le hook rest_post_dispatch : capturer les réponses
- Résultat concret : des logs lisibles
Le problème : quand tes stocks font n’importe quoi
Le topo de base
- Site WooCommerce en production
- Mises à jour automatiques via l’API REST WooCommerce (prix, stocks, etc.)
- Un service externe qui communique avec WooCommerce
- Des différences qui apparaissent au hasard et qui rendent tout le monde dingue
Le souci technique
Sans logs, t’es un détective sans indice. Qui ment ? Le service externe ? WooCommerce ? Un plugin random ? Aucune idée. C’est exactement pour ça que mettre en place des logs sur les endpoints REST WooCommerce devient indispensable quand tu dois sécuriser ton site WooCommerce et garantir la fiabilité de tes intégrations.
Pourquoi logger l’API REST WooCommerce ?
Les logs, c’est tes yeux dans le noir. Avec la documentation officielle WooCommerce REST API, on va pouvoir :
- Voir toutes les requêtes qui arrivent : méthode HTTP, route, paramètres, body
- Savoir qui fait quoi et quand : utilisateur, IP, user agent, timestamp précis
- Mesurer les temps de réponse : identifier les goulets d’étranglement et optimiser les performances
- Détecter les problèmes avant qu’ils explosent : repérer les erreurs 400, 500 et comportements anormaux
- Auditer la sécurité : tracer les tentatives d’accès non autorisées
Le monitoring API WooCommerce n’est plus une option quand tu gères des intégrations critiques comme les synchronisations de stocks, les imports produits massifs ou les connexions ERP.
Le hook rest_pre_dispatch : capturer les requêtes entrantes
Comprendre le hook WordPress
Le hook rest_pre_dispatch se déclenche avant que la requête soit traitée par l’API REST WooCommerce. C’est pile le bon moment pour capturer ce qui arrive.
add_filter( 'rest_pre_dispatch', array( $this, 'log_request' ), 10, 3 );
Code complet pour logger les requêtes
Voilà comment capturer intelligemment les données avec le rest_pre_dispatch hook :
public function log_request( $result, $server, $request ) {
$route = $request->get_route();
// On filtre : logger uniquement ce qui nous intéresse
if ( ! $this->should_log_route( $route ) ) {
return $result;
}
// Démarrage du chronomètre pour mesurer le temps d'exécution
$this->request_start_time = microtime( true );
// Capture de toutes les données pertinentes
$this->request_data = array(
'timestamp' => current_time( 'mysql' ),
'route' => $route,
'method' => $request->get_method(),
'params' => $request->get_params(),
'body' => $request->get_body(),
'user_id' => get_current_user_id(),
'user_login' => wp_get_current_user()->user_login ?: 'Guest',
'ip_address' => $this->get_client_ip(),
'user_agent' => isset( $_SERVER['HTTP_USER_AGENT'] ) ? sanitize_text_field( $_SERVER['HTTP_USER_AGENT'] ) : 'Unknown',
);
return $result;
}Filtrer intelligemment les routes à logger
Ne log pas tout et n’importe quoi ! Concentre-toi sur ce qui compte pour éviter de saturer ton serveur et tes fichiers de logs :
private function should_log_route( \$route ) {
// Routes critiques pour le debug API WooCommerce
$routes_to_log = array(
'/wc/v3/products',
// autres routes
);
foreach ( $routes_to_log as $pattern ) {
if ( strpos( $route, $pattern ) !== false ) {
return true;
}
}
return false;
}
Le hook rest_post_dispatch : capturer les réponses
Pourquoi capturer les réponses ?
Le deuxième hook rest_post_dispatch se déclenche après le traitement de la requête par l’API REST. C’est là qu’on récupère le résultat, le status code et le temps d’exécution total.
add_filter( 'rest_post_dispatch', array( $this, 'log_response' ), 10, 3 );
Code complet pour logger les réponses
Voici comment utiliser le hook rest_post_dispatch pour un debugging WooCommerce efficace :
public function log_response( $result, $server, $request ) {
$route = $request->get_route();
// Vérification de la route et des données de requête
if ( ! $this->should_log_route( $route ) || empty( $this->request_data ) ) {
return $result;
}
// Calcul du temps d'exécution avec microtime()
$execution_time = microtime( true ) - $this->request_start_time;
// Récupération des données de réponse
$response_data = $result->get_data();
$status_code = $result->get_status();
// Préparation du log complet avec toutes les infos
$log_entry = array(
'request' => $this->request_data,
'response' => array(
'status_code' => $status_code,
'execution_time' => round( $execution_time, 4 ) . 's',
'response_summary' => $this->get_response_summary( $response_data, $route ),
),
);
// Écriture du log dans le fichier
$this->write_log( $log_entry );
// Nettoyage des données temporaires
$this->request_data = array();
return $result;
}Note : La fonction microtime() de PHP (voir documentation PHP officielle) permet de mesurer précisément le temps d’exécution en secondes avec 4 décimales. C’est optionnel mais c’est toujours intéressant.
Ma méthode get_response_summary sert simplement à récupérer un résumé des informations histoire de ne pas tout avoir dans les logs (volumétrie)
Plus précis ?
Les hooks et la façon dont je logs mes informations sont bien évidemment à ajuster en fonction de vos besoins. Mais on oublie jamais : la volumétrie, une rotation des logs, on protège le dossier des logs etc…
Résultat concret : des logs lisibles et utiles
Exemple de log GET (lecture de produit)
Voici à quoi ressemble un log bien formaté pour une requête GET sur l’API REST WooCommerce :
[2025-12-05 20:43:15] GET /wc/v3/products/xxxx/variations/xxxxx | User: samy (ID: 42) | IP: 192.168.1.100 | Status: 200 | Time: 0.0248s
Request: {"params":{"include":"xxxxx"},"body":""}
Response: {"product_id": xxxxx,"name":"T-shirt Rouge Taille M","type":"variation","price":"29.99","stock_quantity":45}Exemple de log POST (mise à jour)
Et pour une requête POST de mise à jour massive via /wc/v3/products/batch :
[2025-12-08 08:00:41] POST /wc/v3/products/batch | User: samy (ID: 42) | IP: 192.168.1.100 | Status: 200 | Time: 1.1479s
Request: {"params":{"update":[{"id":xxxx,"regular_price":"900","stock_quantity":5},{"id":xxxx,"regular_price":"50","stock_quantity":169}]},"body":"{ \"update\":[ { \"id\":xxx, \"regular_price\":\"600\", \"stock_quantity\":1 }, { \"id\":xxx, \"regular_price\":\"7\", \"stock_quantity\":666 } ] }"}
Response: {"update":[{"id":xxxx,"status":"success"},{"id":xxxx,"status":"success"}]}Le happy ending : bug identifié
Après 3-4 jours avec le système de logs WooCommerce actif, le service externe me rappelle pour le même problème de stocks décalés. Cette fois ? J’ai identifié le coupable en quelques minutes grâce aux logs détaillés : leur ancien serveur qui continuait à faire des appels API en douce.
Un truc tout con, mais sans mettre des logs sur l’API REST, j’aurais pu chercher pendant des semaines en testant toutes les hypothèses possibles. Clairement, on ne m’avait pas donné l’information d’un nouveau serveur et manque de bol, le changement de serveur quasiment au moment où j’arrive sur le projet …. Avec mes logs, j’ai pu facilement voir plusieurs appels réalisant sensiblement les mêmes modifications de produits MAIS une IP différente -> et c’est bien ça qui m’a permis de faire un retour pertinent au service externe et ainsi leur permettre de résoudre le problème rapidement.
Maintenant, à toi de jouer ! Si tu te retrouves dans la même situation, avant de chercher dans le vide, pense aux logs, pense à te rajouter de l’aide.
