Un plugin de formulaire qui renvoie une page blanche après un changement de PHP sur le serveur, on a tous vu ça au moins une fois. Le problème ne vient presque jamais du cœur de WordPress, mais d’un composant périphérique (thème, extension, bout de code custom) qui utilise une fonction dépréciée dans la nouvelle branche PHP. Comprendre où se situent les vrais points de friction évite de passer une demi-journée à restaurer une sauvegarde.
Pile complète WordPress et PHP : le maillon faible n’est pas le cœur
WordPress lui-même suit un calendrier d’alignement avec les branches PHP publiées chaque année en novembre. Le cœur est généralement prêt pour la nouvelle version PHP quelques mois après sa sortie. Le risque réel se cache ailleurs.
On constate que les incompatibilités viennent presque toujours d’un plugin ou d’un thème qui n’a pas été mis à jour pour la branche PHP ciblée. Un site avec cinq extensions bien maintenues migrera sans accroc. Un site avec vingt plugins, dont trois abandonnés depuis deux ans, posera problème quelle que soit la version visée.
Le critère de confiance a évolué : les mainteneurs recommandent de vérifier la mention « Tested up to » et la date de dernière mise à jour sur la fiche de chaque extension. Un plugin mis à jour il y a plus d’un an, sans mention de compatibilité avec la branche PHP courante, représente un signal d’alerte concret.
Les composants à auditer avant toute migration PHP
- Le thème actif et, le cas échéant, le thème enfant : vérifier que le développeur a publié une mise à jour récente mentionnant la branche PHP cible.
- Chaque plugin actif, en consultant l’onglet « Tested up to » dans le répertoire officiel WordPress ou sur la documentation de l’éditeur.
- Le code personnalisé (fonctions ajoutées dans functions.php, snippets via mu-plugins) : certaines fonctions PHP dépréciées provoquent des erreurs fatales sans avertissement préalable.
- Les extensions serveur (modules PHP comme ionCube, imagick, intl) dont dépendent certains plugins de cache, d’optimisation d’images ou de traduction.
Compatibilité thèmes et plugins WordPress avec PHP 8
La branche PHP 8 introduit des changements de comportement qui ne génèrent pas toujours une erreur visible. Dans certains cas, une fonction retourne un type différent, et le site semble fonctionner alors qu’un flux métier (paiement, envoi de mail, génération de PDF) est silencieusement cassé.
Les thèmes premium commerciaux (ceux distribués via ThemeForest ou directement par leurs éditeurs) suivent des cycles de mise à jour variables. Certains éditeurs publient un patch de compatibilité PHP dans les semaines suivant la sortie d’une nouvelle branche. D’autres attendent plusieurs mois. Vérifier le changelog du thème avant de toucher à PHP reste la précaution la plus fiable.
Côté plugins, le constat est identique. Les extensions massivement installées (formulaires, SEO, cache, constructeurs de pages) sont en général compatibles rapidement. Les retours varient davantage sur les plugins de niche ou les extensions développées sur mesure par une agence il y a quelques années.
Test en environnement de staging
On ne migre pas PHP sur un site en production sans test préalable. La méthode terrain consiste à créer un environnement de staging avec la version PHP cible, puis à parcourir chaque flux critique : page d’accueil, formulaire de contact, tunnel d’achat, espace membre, flux RSS. Beaucoup d’hébergeurs proposent un outil de staging en un clic dans leur panneau d’administration.
Si le staging révèle une erreur, on identifie le composant fautif en désactivant les plugins un par un. Cette approche par élimination reste plus rapide que l’analyse de logs PHP pour la plupart des profils non-développeurs.
Hébergeurs WordPress et gestion de la version PHP
Le changement de version PHP passe par le panneau de l’hébergeur, pas par l’administration WordPress. C’est un paramètre d’infrastructure, et le chemin diffère selon les plateformes.
Sur un hébergement mutualisé avec cPanel, on trouve généralement l’option dans la section « Select PHP Version » ou « MultiPHP Manager ». Sur un hébergement managé WordPress, certains hébergeurs gèrent la migration PHP automatiquement et informent le client par email avant bascule. D’autres laissent le choix mais bloquent les versions en fin de vie.
Ce que l’hébergeur contrôle (et ce qu’il ne contrôle pas)
L’hébergeur fournit la version PHP et les extensions serveur associées. Il ne vérifie pas la compatibilité de vos thèmes ou plugins avec la branche sélectionnée. Cette responsabilité reste côté site.
Certains hébergeurs proposent un outil de vérification de compatibilité PHP intégré, qui scanne le code des extensions installées et signale les fonctions dépréciées. Quand cet outil existe, on l’utilise systématiquement avant de valider la bascule.
Checklist concrète avant de changer de version PHP WordPress
Pour éviter les mauvaises surprises, on suit un ordre précis. Cette séquence fonctionne aussi bien pour un passage de PHP 7.4 vers 8 que pour une montée de version mineure au sein de la branche 8.
- Mettre à jour WordPress, tous les plugins et le thème actif vers leurs dernières versions stables avant de toucher à PHP.
- Vérifier la mention « Tested up to » de chaque plugin et la date de dernière mise à jour du thème : un composant non mis à jour depuis plus d’un an est le premier suspect.
- Réaliser une sauvegarde complète (fichiers et base de données) et vérifier qu’on peut la restaurer.
- Basculer PHP sur l’environnement de staging, tester chaque flux métier, puis seulement appliquer le changement en production.
- Surveiller les logs d’erreurs PHP pendant les premières heures après migration pour détecter des warnings silencieux.
Un point souvent négligé : les tâches planifiées (WP-Cron, envoi d’emails automatiques, synchronisation de stock). Elles s’exécutent en arrière-plan et peuvent échouer sans que personne ne s’en aperçoive pendant des jours. Tester les crons manuellement après la bascule fait partie du contrôle post-migration.
La version PHP de votre serveur conditionne la performance et la sécurité de votre site WordPress, mais le vrai travail se joue sur la compatibilité de chaque composant installé. Un site avec peu de plugins bien maintenus migrera sans friction. Un site chargé d’extensions datées demandera un audit préalable, et parfois le remplacement de certains composants avant toute montée de version.
