Un site WooCommerce qui affiche une erreur fatale après une montée de version PHP, alors que WordPress core fonctionne sans broncher : nous observons ce scénario régulièrement. Le problème ne vient presque jamais de PHP seul. Il vient de la compatibilité réelle entre PHP, WooCommerce, les extensions et le thème actif. Cet article détaille les points de rupture concrets et les méthodes pour les anticiper.
Compatibilité WooCommerce et PHP : pourquoi un site casse malgré une version récente
Une version PHP récente ne garantit rien si la pile applicative n’a pas été validée dans son ensemble. WooCommerce dépend de dizaines de hooks, de filtres et de fonctions dépréciées que les extensions tierces utilisent sans contrôle de version.
Lire également : Intranet Normandie : guide d'accès rapide pour tous les agents
Le cas typique : PHP 8.3 est déployé, WordPress tourne, mais le tunnel de commande renvoie une erreur critique. La cause se trouve souvent dans une extension de paiement ou de livraison qui appelle une fonction avec un typage incompatible (passage de null là où PHP 8+ attend une string).
Les recommandations récentes vont au-delà du simple choix d’une version « récente ». La règle opérationnelle est de choisir la version stable la plus récente qui passe réellement les tests avec WordPress, WooCommerce, les extensions, le thème et la configuration serveur. « Plus neuf » n’est pas automatiquement « plus sûr » si la compatibilité n’est pas validée.
A découvrir également : Webmailversailles en déplacement : accéder à votre messagerie en toute sécurité hors établissement
Les points de rupture fréquents en PHP 8.x
- Les fonctions qui acceptaient des paramètres null en PHP 7.4 déclenchent des TypeError en PHP 8.1+. WooCommerce lui-même a corrigé ces cas, mais beaucoup d’extensions de passerelles de paiement ou de gestion de stock ne l’ont pas fait.
- Les notices PHP transformées en erreurs fatales : ce qui générait un simple warning en 7.4 peut provoquer un écran blanc en 8.x, notamment sur les calculs de taxes ou les règles de livraison conditionnelles.
- Les modifications de comportement de json_serialize et des fonctions de chaîne (str_contains, str_starts_with) cassent le code métier custom qui n’a pas été réécrit.
Diagnostic des bugs critiques WooCommerce après migration PHP
Avant de baisser la version PHP par réflexe, nous recommandons un diagnostic structuré. Le problème est rarement PHP lui-même, mais un composant précis de la pile.
Activer le log d’erreurs PHP côté serveur
Dans wp-config.php, positionner WP_DEBUG_LOG sur true sans activer WP_DEBUG_DISPLAY. Le fichier debug.log livrera la trace exacte : nom du fichier, ligne, type d’erreur. Sur un hébergement mutualisé, vérifier que le fichier est bien accessible via le gestionnaire de fichiers ou SFTP.
La trace pointe presque toujours vers un fichier d’extension ou de thème, pas vers le core WordPress. C’est cette information qui oriente la suite.
Isoler le composant fautif sans couper la production
Les hébergeurs proposent désormais des gestionnaires PHP distincts par domaine, sous-domaine ou même dossier (via cPanel MultiPHP Manager, Plesk ou des panneaux propriétaires). Sur un site WooCommerce, cette granularité permet de tester une version PHP sur un clone ou un sous-domaine staging sans toucher à la boutique en production.
La méthode fiable : cloner le site sur un environnement de staging, monter la version PHP cible, puis activer les extensions une par une. Le plugin qui déclenche l’erreur est identifié en quelques minutes. Ce séquencement « clone, test, bascule, contrôle » reste la seule pratique sérieuse de réduction du risque.
Plugins WordPress et sécurité PHP : le maillon faible de la chaîne
WooCommerce publie des correctifs de sécurité à un rythme soutenu. La version 9.0.3 a par exemple fait l’objet d’un correctif d’urgence quelques semaines après sa sortie pour une faille critique exploitable avant connexion. Attendre la prochaine « grosse » mise à jour ne suffit pas : chaque version de sécurité successive doit être appliquée.
Le vrai risque se situe sur les extensions secondaires. Un plugin de personnalisation produit, une passerelle de paiement locale ou un connecteur ERP peuvent rester des mois sans correctif. Pendant ce temps, le code vulnérable tourne sur une version PHP qui n’a plus de support de sécurité.
Critères pour auditer la fiabilité d’un plugin WooCommerce
- Date du dernier commit sur le dépôt officiel ou le changelog : au-delà de six mois sans mise à jour, le risque de dette technique est élevé.
- Compatibilité PHP déclarée dans le readme.txt : si le plugin ne mentionne pas explicitement PHP 8.2 ou 8.3, considérer qu’il n’a pas été testé.
- Présence de notices de dépréciation dans les logs : même sans erreur fatale, les notices signalent du code qui cassera à la prochaine montée de version.
- Utilisation de fonctions WooCommerce dépréciées (CRUD direct sur les tables au lieu de l’API HPOS) : signe d’un plugin qui n’a pas suivi l’évolution de WooCommerce.
Stratégie de migration PHP pour un site WooCommerce en production
Nous recommandons de ne jamais sauter deux versions majeures de PHP en une seule opération. Passer de 7.4 à 8.3 directement multiplie les surfaces de rupture. Un palier intermédiaire (7.4 vers 8.1, puis 8.1 vers 8.3) permet d’isoler les incompatibilités à chaque étape.
La sauvegarde complète (fichiers et base de données) avant toute bascule est un prérequis non négociable. Sur WooCommerce, cela inclut les tables personnalisées créées par les extensions de gestion de commandes ou d’abonnements.
Après la bascule : vérifications critiques
Le tunnel de commande est le premier élément à tester. Passer une commande de bout en bout (ajout panier, page checkout, paiement test, confirmation, email transactionnel) permet de détecter les régressions que les tests automatisés ne couvrent pas toujours.
Vérifier ensuite les tâches cron WooCommerce (traitement des webhooks, synchronisation des stocks, envoi des emails de relance). Ces processus tournent en arrière-plan et une incompatibilité PHP peut les bloquer silencieusement pendant des jours avant qu’un symptôme visible n’apparaisse.
PHP 8.2 arrive en fin de support de sécurité fin 2026. Les sites qui tournent encore sur cette version doivent planifier la migration vers PHP 8.3 comme standard de stabilité et de performance pour WordPress et WooCommerce. Attendre le dernier moment, c’est accepter de devoir migrer dans l’urgence, sans environnement de test, avec un risque direct sur le chiffre d’affaires de la boutique.
