WordPress 7.1 : vérifier la compatibilité PHP 8.5

La mise à niveau de PHP est une opération de maintenance aussi importante qu’une mise à jour de WordPress, d’un thème ou d’une extension. Lorsqu’un hébergeur propose PHP 8.5, il peut être tentant d’activer immédiatement cette version pour bénéficier d’un environnement plus récent. Pourtant, un changement de version PHP agit directement sur l’exécution de tout votre site : WordPress, extensions, thème, mu-plugins, scripts personnalisés et tâches planifiées.

Dans le cadre de la préparation de WordPress 7.1, la compatibilité avec PHP 8.5 doit donc faire l’objet d’un contrôle spécifique. Le but n’est pas seulement d’éviter une page blanche : il s’agit de repérer les fonctions obsolètes, les dépendances non maintenues et les erreurs qui n’apparaissent parfois que sur un parcours précis, comme la validation d’une commande WooCommerce, l’envoi d’un formulaire ou l’exécution d’un cron.

Ce guide propose une méthode opérationnelle pour auditer le site, reproduire l’environnement dans une préproduction, lire les erreurs utiles et organiser un basculement maîtrisé. Il complète notre checklist avant la mise à jour de WordPress 7.1 : ici, l’attention porte sur le serveur et le moteur PHP.

Pourquoi PHP 8.5 doit entrer dans votre plan de maintenance

PHP est le langage qui exécute WordPress. Une version plus récente peut corriger des bugs, supprimer des comportements anciens et déprécier certaines syntaxes ou fonctions. Cela signifie qu’un code qui fonctionnait sous une version antérieure de PHP peut déclencher un avertissement, puis une erreur, sous PHP 8.5.

La compatibilité ne dépend pas exclusivement du cœur WordPress. Elle repose sur plusieurs couches :

la version de WordPress installée ;
le thème actif et, le cas échéant, le thème enfant ;
les extensions actives, mais aussi certaines extensions désactivées encore chargées par des mécanismes spécifiques ;
les extensions indispensables déposées dans wp-content/mu-plugins ;
le code personnalisé ajouté dans functions.php, un plugin maison ou des snippets ;
les bibliothèques chargées par Composer ou intégrées à une extension ;
la configuration de l’hébergement : extensions PHP, limite mémoire, OPcache, tâches cron et cache serveur.

Il ne faut donc pas assimiler « WordPress 7.1 fonctionne avec PHP 8.5 » à « mon site fonctionnera avec PHP 8.5 ». WordPress peut être compatible, tandis qu’une seule extension ancienne bloque l’administration ou rend indisponible une fonctionnalité métier.

Une incompatibilité PHP peut prendre plusieurs formes : erreur fatale à l’ouverture d’une page, écran blanc, erreur HTTP 500, boucle de redirection, formulaire qui ne s’envoie plus ou tâche cron interrompue. Les symptômes peuvent aussi être discrets. Par exemple, une erreur dans un appel AJAX ne sera visible que dans les outils de développement du navigateur ou dans les journaux PHP.

La bonne question n’est pas « puis-je activer PHP 8.5 ? », mais « puis-je démontrer, sur une copie réaliste de mon site, que ses fonctions importantes restent opérationnelles avec PHP 8.5 ? »

Une migration PHP planifiée s’intègre naturellement dans une routine de maintenance WordPress mensuelle. Elle évite aussi les changements imposés dans l’urgence lorsque l’hébergeur retire une ancienne version de PHP.

Commencer par inventorier l’environnement existant

Avant de modifier quoi que ce soit, établissez un état des lieux. Cette étape offre un point de comparaison après les tests et permet d’identifier les composants qui nécessitent une vérification particulière.

Dans l’administration WordPress, ouvrez Outils > Santé du site > Informations. Les sections « Serveur », « WordPress », « Thème actif » et « Extensions actives » donnent déjà des éléments utiles : version de PHP courante, version de WordPress, thème utilisé et liste des extensions.

Pour un inventaire reproductible, WP-CLI est particulièrement pratique. Depuis la racine du site, les commandes suivantes permettent de relever les versions principales :

wp core version
wp plugin list
wp theme list
wp option get active_plugins --format=json

La commande wp plugin list indique notamment si une extension est active et si une mise à jour est disponible. Conservez le résultat dans votre ticket de maintenance ou dans un fichier daté. Pour un site multisite, contrôlez également les extensions activées pour le réseau.

Ajoutez à cet inventaire les éléments qui échappent souvent à la liste standard :

les dossiers présents dans wp-content/mu-plugins ;
les snippets ajoutés via une extension dédiée ou dans le thème enfant ;
les scripts de déploiement et les dépendances Composer ;
les connecteurs externes : paiement, ERP, CRM, emailing, API métier ;
les tâches lancées via le cron système ou WP-Cron ;
les réglages PHP définis dans le panneau d’hébergement, dans un fichier .user.ini, php.ini ou dans la configuration du serveur.

Profitez-en pour retirer ce qui n’est plus utile. Les extensions inutilisées ne doivent pas rester installées indéfiniment : elles compliquent l’audit et peuvent créer un risque de sécurité. Notre guide sur les plugins WordPress abandonnés aide à décider s’il faut mettre à jour, remplacer ou supprimer un composant.

Auditer le cœur WordPress, le thème et les extensions

L’audit de compatibilité commence par les sources officielles. Consultez la page de l’extension dans le répertoire WordPress, son changelog, sa documentation et les annonces de son éditeur. Cherchez une mention explicite de PHP 8.5, mais ne concluez pas trop vite en l’absence de mention : certains éditeurs ne publient pas une matrice détaillée de versions PHP.

Pour le cœur, vérifiez les recommandations et exigences actualisées sur la page WordPress Requirements. Pour WordPress 7.1, appuyez-vous également sur les notes de publication et la documentation officielle correspondant précisément à votre version installée. Les informations peuvent évoluer entre une version majeure et les correctifs ultérieurs.

Classer les extensions selon leur niveau de risque

Toutes les extensions ne méritent pas le même niveau d’effort. Classez-les pour prioriser les essais :

Critique : e-commerce, paiement, authentification, sauvegarde, sécurité, cache, formulaires de contact, connexion à un service métier.
Importante : SEO, constructeur de pages, traduction, gestion des médias, redirections, champs personnalisés.
Secondaire : fonctionnalités éditoriales ou visuelles non essentielles au fonctionnement du site.

Un plugin de paiement doit être testé avec le tunnel de commande complet, pas uniquement en vérifiant que son menu s’affiche dans l’administration. De même, un plugin de cache demande des tests sur les pages non connectées, les contenus personnalisés et, si applicable, les paniers WooCommerce.

Ne pas oublier le code sur mesure

Les incompatibilités les plus difficiles à identifier proviennent fréquemment d’un développement local : code dans functions.php, plugin privé, intégration d’API ou modification d’un thème enfant. Ce code n’est pas toujours analysé par l’éditeur d’une extension et peut ne pas avoir été révisé depuis plusieurs années.

Un audit statique peut compléter les tests manuels. Le standard PHPCompatibility, utilisé avec PHP_CodeSniffer, aide à repérer des constructions incompatibles avec une plage de versions PHP définie. Pour du code WordPress, le projet PHPCompatibilityWP fournit des règles complémentaires.

Ces outils ne remplacent pas l’exécution réelle du site. Ils signalent des motifs connus dans le code analysé, mais ils ne valident ni la configuration de l’hébergement, ni les appels à des services distants, ni les scénarios fonctionnels. Utilisez-les pour accélérer la détection, puis confirmez chaque correction sur la préproduction.

Créer une préproduction fidèle et isolée

Le principe fondamental est simple : ne faites pas le premier test PHP 8.5 sur le site en ligne. Créez une préproduction, aussi proche que possible de la production, mais inaccessible aux visiteurs et aux moteurs de recherche.

Selon votre hébergeur, vous pouvez utiliser une fonction de staging, un sous-domaine protégé ou un environnement local. Les outils comme Local, DDEV ou Docker peuvent convenir au développement. Toutefois, lorsqu’un problème dépend de la configuration de l’hébergement, une préproduction hébergée sur une infrastructure comparable à la production est plus représentative.

Une préproduction utile comprend :

une copie des fichiers WordPress ;
une copie de la base de données ;
la même version de WordPress, du thème et des extensions que la production au point de départ ;
une version de PHP 8.5 activable indépendamment de la production ;
une protection par mot de passe ou une restriction d’accès ;
une interdiction d’indexation, par exemple via les réglages WordPress et une protection serveur adaptée.

Après le clonage, adaptez les paramètres sensibles. Désactivez l’envoi réel d’e-mails, les passerelles de paiement en production, les webhooks métier ou les synchronisations qui pourraient écrire des données externes. Si votre site e-commerce utilise Stripe, PayPal ou un autre prestataire, utilisez les mécanismes de test prévus par le service lorsque cela est possible.

Vérifiez aussi les URL, les permaliens, les clés d’API et les tâches planifiées. Une préproduction qui envoie des newsletters à de vrais abonnés ou qui remonte de faux événements dans un CRM ne constitue pas un environnement de test sûr.

Activer PHP 8.5 en préproduction et observer les journaux

Une fois la préproduction prête, changez sa version PHP depuis le panneau de l’hébergeur ou la configuration de l’environnement. La méthode varie selon le fournisseur ; l’essentiel est de confirmer que le processus PHP utilisé par le site est bien PHP 8.5.

Contrôlez ensuite l’information dans Outils > Santé du site > Informations > Serveur. Ne vous fiez pas uniquement au réglage affiché dans un tableau de bord d’hébergement : une configuration locale ou un pool PHP distinct peut modifier le résultat effectif.

Activez temporairement le journal de débogage WordPress dans la préproduction, sans afficher les messages aux visiteurs :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Avec cette configuration, WordPress écrit les messages dans wp-content/debug.log lorsque l’écriture est autorisée. Consultez également le journal d’erreurs PHP disponible chez l’hébergeur. Une erreur fatale PHP peut survenir avant que WordPress n’ait la possibilité d’écrire dans son propre fichier de log.

Évitez d’activer WP_DEBUG_DISPLAY sur la production. Afficher un message technique à l’écran peut divulguer des chemins de fichiers, des noms d’extensions ou d’autres informations qui ne doivent pas être publiques.

Lire les erreurs avec méthode

Une ligne de journal utile contient généralement un type d’erreur, un fichier et un numéro de ligne. Commencez par identifier le composant responsable. Si le chemin mène à wp-content/plugins/nom-du-plugin, vérifiez d’abord les mises à jour et la documentation de cette extension. S’il mène à votre thème enfant ou à un plugin privé, transmettez l’information au développeur en conservant le message complet et le contexte de reproduction.

Ne corrigez pas une erreur en modifiant directement les fichiers du cœur WordPress ou d’une extension tierce. La modification serait écrasée à la prochaine mise à jour et pourrait masquer un problème plus large. Préférez une mise à jour officielle, un correctif maintenu dans votre dépôt ou le remplacement du composant.

Exécuter des tests fonctionnels plutôt qu’une simple visite

Une page d’accueil qui s’affiche ne prouve pas la compatibilité du site. Après l’activation de PHP 8.5, déroulez une recette de test centrée sur les usages réels. Préparez-la avant le changement afin de comparer les résultats objectivement.

Voici une base de contrôle à adapter :

ouvrir les pages principales en navigation privée ;
tester la connexion, la déconnexion et la réinitialisation de mot de passe ;
créer, modifier et prévisualiser un article ou une page ;
téléverser un média et vérifier les miniatures ;
envoyer chaque type de formulaire important ;
tester la recherche interne, les filtres et les contenus dynamiques ;
vérifier les menus, les modèles de page, le thème mobile et les blocs ;
contrôler les appels AJAX et REST utilisés par l’administration ou le front-end ;
pour WooCommerce, parcourir le catalogue, ajouter un produit au panier et réaliser un essai avec un moyen de paiement de test ;
lancer, lorsque c’est pertinent, les imports, exports, sauvegardes et tâches planifiées.

Utilisez les outils de développement du navigateur pour repérer les requêtes en échec dans l’onglet réseau. Un code HTTP 500 ou une réponse AJAX vide peut signaler une erreur PHP que l’interface ne montre pas clairement.

Pour les tâches WordPress planifiées, WP-CLI peut aider à les lister :

wp cron event list

Cette vérification ne remplace pas l’observation d’une tâche réellement exécutée, mais elle confirme que les événements sont présents. Pour les sites qui dépendent d’un cron système, examinez aussi la configuration côté hébergeur.

Corriger, mettre à jour ou remplacer les composants incompatibles

Lorsqu’un test révèle une erreur, appliquez une démarche progressive. Commencez par mettre à jour WordPress, les extensions et le thème dans la préproduction, après avoir vérifié les notes de version. Une correction de compatibilité PHP est parfois déjà publiée par l’éditeur.

Si l’erreur persiste, isolez le composant. Vous pouvez désactiver temporairement une extension sur la préproduction, refaire le scénario, puis la réactiver. Cette méthode permet de confirmer une cause, à condition de noter chaque action pour ne pas tirer de conclusion hâtive.

Les options de résolution sont généralement les suivantes :

installer une version corrigée fournie par l’éditeur ;
corriger le code personnalisé avec un développeur ;
remplacer l’extension par une solution activement maintenue ;
retarder le basculement PHP si une dépendance critique n’a pas de solution immédiate.

Le report doit rester une décision documentée, pas un oubli. Inscrivez le composant concerné, le symptôme, la version testée, l’impact métier et la date de réévaluation dans votre suivi de maintenance. C’est particulièrement important pour les extensions qui touchent à la sécurité, à la sauvegarde ou au paiement.

Si vous suspectez une corruption de fichiers après une mise à jour, la commande WP-CLI suivante peut vérifier les sommes de contrôle du cœur WordPress :

wp core verify-checksums

Elle ne contrôle pas les fichiers de thèmes ou d’extensions, mais elle permet d’écarter une altération du cœur téléchargé depuis WordPress.org.

Planifier le basculement de PHP 8.5 en production

Lorsque la préproduction est validée, préparez l’intervention de production. Choisissez un créneau où l’activité est faible et où une personne compétente peut surveiller le site. Pour un e-commerce ou un site de réservation, évitez les périodes commerciales importantes.

Avant le changement, réalisez et vérifiez une sauvegarde complète : fichiers, base de données et, si votre hébergeur le permet, point de restauration de l’environnement. Une sauvegarde utile est une sauvegarde dont la restauration est possible ; conservez donc la procédure et les accès nécessaires.

Votre plan de basculement peut suivre cette séquence :

confirmer que la production possède les mêmes versions validées en préproduction ;
réaliser une sauvegarde juste avant l’opération ;
noter la version PHP actuelle et la méthode exacte de retour arrière ;
activer PHP 8.5 ;
vider les caches applicatifs, serveur et CDN selon votre architecture ;
vérifier immédiatement les pages et parcours prioritaires ;
surveiller les journaux PHP et WordPress après le basculement ;
revenir à la version PHP précédente si une fonction critique échoue et qu’aucun correctif rapide n’est validé.

Après le déploiement, répétez une version courte de la recette menée en préproduction. Contrôlez également les formulaires, les e-mails transactionnels, les commandes éventuelles et l’accès à l’administration. Pour compléter ces vérifications après une modification technique, consultez notre guide des contrôles après mise à jour d’un plugin ou d’un thème.

Faire de la compatibilité PHP un contrôle récurrent

La compatibilité PHP n’est pas un contrôle unique lié à WordPress 7.1. Chaque nouvelle extension, modification de thème ou intégration personnalisée peut modifier le résultat de vos futurs tests. Conservez donc une préproduction fonctionnelle et une recette adaptée aux parcours essentiels de votre site.

Documentez les versions PHP supportées, les composants critiques et les résultats des essais. Ce suivi raccourcit considérablement les diagnostics lors d’une erreur et facilite les décisions lorsque votre hébergeur annonce l’évolution de ses environnements.

En anticipant PHP 8.5 avec un inventaire précis, des tests réalistes et un plan de retour arrière, vous réduisez le risque de panne au moment de préparer WordPress 7.1. Si votre site repose sur des extensions nombreuses, du code métier ou une boutique en ligne, intégrez cet audit à votre prochaine opération de maintenance : quelques contrôles en préproduction coûtent toujours moins cher qu’une indisponibilité en production.