# WooCommerce Analytics sous PHP 8.2 : pourquoi certains rapports ne se génèrent

> Les graphiques restent désespérément à zéro après une montée en PHP 8.2. La cause : une fonction dépréciée nichée dans le moteur de rapports.

- Auteur : WordPress Développement
- Publié le : 2023-03-04
- Mis à jour le : 2023-03-04
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/woocommerce-analytics-php82-rapports-vides/

## L’essentiel

- Le symptôme apparaît uniquement sur les rapports par période personnalisée
- La cause est une fonction PHP dépréciée dans le calcul d'intervalles
- Le correctif tient en un filtre, sans toucher au cœur de WooCommerce

« 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 214
```

## Diagnostic : une dépréciation qui casse un calcul silencieusement

> L'essentiel à retenir : Le symptôme apparaît uniquement sur les rapports par période personnalisée ; La cause est une fonction PHP dépréciée dans le calcul d'intervalles ; Le correctif tient en un filtre, sans toucher au cœur de WooCommerce

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_LOG` sur 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/catch` trop 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.