« Aucune donnée sur cette période. » Le message s’affichait sur l’onglet Analytics de WooCommerce, alors que les commandes s’accumulaient normalement dans la base et que le tableau de bord classique affichait bien le chiffre d’affaires du jour.
Le contexte : une montée de version d’hébergement mutualisé, passée de PHP 8.0 à PHP 8.2 dans la foulée d’une campagne de mise à jour de sécurité côté hébergeur. Rien n’avait changé côté WordPress ni côté WooCommerce. Seul l’interpréteur PHP avait bougé.
Symptôme : des rapports vides, mais pas tous
Le tableau de bord principal (chiffre d’affaires du jour, commandes en attente) continuait de fonctionner. Seuls les rapports du module Analytics avec une période personnalisée — « du 1er au 15 du mois », par exemple — renvoyaient un jeu de données vide, sans message d’erreur visible côté interface. Aucune ligne dans les journaux WooCommerce classiques (wc-logs).
C’est en activant WP_DEBUG_LOG avec WP_DEBUG_DISPLAY désactivé que l’erreur est apparue dans debug.log :
PHP Deprecated: Function utf8_encode() is deprecated in .../wc-admin/includes/reports/class-wc-admin-reports-interval.php on line 214Diagnostic : une dépréciation qui casse un calcul silencieusement
PHP 8.2 a marqué utf8_encode() et utf8_decode() comme dépréciées. Dans la plupart des cas, une fonction dépréciée continue de fonctionner et se contente d’émettre un avertissement inoffensif. Le problème ici tenait à la configuration de l’hébergeur : les avertissements PHP étaient convertis en exceptions par un gestionnaire d’erreurs personnalisé installé au niveau du serveur, pour des raisons de conformité interne. Résultat : l’appel levait une exception fatale, interceptée silencieusement par le bloc try/catch englobant du moteur de rapports WooCommerce, qui retournait alors un tableau vide plutôt que de faire planter la page.
Ce comportement n’est documenté nulle part dans le Codex WooCommerce : c’est la combinaison précise entre une version de WooCommerce antérieure à un correctif amont, PHP 8.2, et une configuration serveur stricte qui produisait ce résultat. Sur un hébergement par défaut sans conversion des avertissements en exceptions, le symptôme n’aurait probablement été qu’un ralentissement, pas un rapport vide.
Correctif : neutraliser l’appel sans toucher au cœur
Modifier directement un fichier du cœur de WooCommerce était exclu — la prochaine mise à jour aurait écrasé le correctif. La solution retenue passe par un filtre qui intercepte la donnée avant l’appel problématique, en s’appuyant sur mb_convert_encoding(), l’équivalent moderne recommandé par la documentation PHP officielle :
add_filter( 'woocommerce_admin_report_export_row', function( $row ) {
foreach ( $row as $key => $value ) {
if ( is_string( $value ) && ! mb_check_encoding( $value, 'UTF-8' ) ) {
$row[ $key ] = mb_convert_encoding( $value, 'UTF-8', 'ISO-8859-1' );
}
}
return $row;
} );Cette rustine a permis de patienter le temps qu’une mise à jour de WooCommerce corrige la dépréciation à la source. La véritable solution, à moyen terme, a été la montée de version de WooCommerce vers une release qui ne fait plus appel à ces fonctions dépréciées dans le moteur de rapports.
Prévention : tester les rapports après chaque montée de PHP
La liste des vérifications désormais systématiques avant toute montée de version PHP sur les boutiques suivies :
- Activer temporairement
WP_DEBUG_LOGsur un environnement de recette identique à la production. - Ouvrir chaque rapport Analytics (ventes, produits, catégories, coupons) avec une période personnalisée.
- Vérifier
debug.logà la recherche du mot-cléDeprecated, même sans erreur visible côté front. - Comparer le comportement du gestionnaire d’erreurs de l’hébergeur en recette et en production, car deux hébergeurs peuvent réagir différemment à une même dépréciation.
Conseil maison : un rapport vide sans message d’erreur est presque toujours un symptôme d’exception avalée par un bloc
try/catchtrop large. Cherchez d’abord dans les journaux serveur bruts, pas dans l’interface WordPress.
En résumé
Le passage à PHP 8.2 n’a rien cassé « de lui-même » dans WooCommerce : il a révélé une dépréciation déjà présente dans le code, restée invisible tant que le gestionnaire d’erreurs du serveur ne la transformait pas en exception bloquante. La leçon dépasse ce cas précis : sur un hébergement mutualisé, la configuration du gestionnaire d’erreurs compte autant que la version de PHP elle-même pour anticiper ce type d’incident.
