Passer WordPress en PHP 8 sans tout casser

Un lundi matin de ce printemps, un domaine viticole girondin nous appelle : son site de réservation de visites et de dégustations affiche une page blanche. Personne n'y a touché depuis des semaines. Pendant la nuit, son hébergeur a simplement fait ce qu'il avait annoncé par email un mois plus tôt, à une adresse que plus personne ne lisait : passer ses serveurs de PHP 7.4 à PHP 8.2. Ce scénario n'a rien d'exceptionnel. Chaque version de PHP, le langage sur lequel tourne WordPress, a une date de fin de vie au-delà de laquelle plus aucun correctif de sécurité n'est publié, et les hébergeurs finissent toujours par suivre ce calendrier. Début 2026, environ 22 % des sites WordPress tournaient pourtant encore en PHP 7.4, une version abandonnée depuis novembre 2022. La mise à jour PHP de WordPress finit donc par s'imposer, et le cœur de WordPress l'encaisse bien : ses versions récentes sont officiellement compatibles avec PHP 8.3, 8.4 et même 8.5. Ce sont les extensions et les thèmes qui coincent, surtout ceux qui ne sont plus mis à jour. Une seule extension incompatible suffit à déclencher une erreur fatale, et une erreur fatale, côté visiteur, c'est l'écran blanc. En tant qu'agence WordPress, nous voyons passer ces migrations forcées chaque année. Cet article en raconte deux, l'une subie, l'autre préparée, et détaille notre méthode pour passer WordPress en PHP 8 sans tout casser, avant que l'hébergeur ne choisisse la date à votre place.

Pourquoi votre hébergeur impose-t-il PHP 8 ?

Une branche de PHP vit quatre ans : deux ans de support actif, puis deux ans de correctifs de sécurité seuls. Ensuite, plus rien. PHP 7.4 est arrivé en fin de vie le 28 novembre 2022, PHP 8.0 le 26 novembre 2023 et PHP 8.1 le 31 décembre 2025. PHP 8.2 ne recevra plus de correctifs après le 31 décembre 2026, PHP 8.3 tiendra jusqu'à fin 2027 et PHP 8.4 jusqu'à fin 2028. Un hébergeur qui garde une version abandonnée sur ses serveurs partagés expose tous ses clients : la version PHP de l'hébergeur n'est donc pas un réglage de confort mais une question de sécurité, et le gain de vitesse, réel mais modeste, vient en prime. Depuis sa version 7.0, WordPress exige au minimum PHP 7.4 mais recommande PHP 8.3 ou plus. Piège du calendrier : passer en 8.2 aujourd'hui n'offre que quelques mois de répit, mieux vaut viser 8.3 ou 8.4. Ce qui casse, c'est que PHP 8 est plus strict. La version 8.0 a supprimé d'anciennes fonctions comme create_function() ou each(), et transformé de nombreux avertissements en erreurs bloquantes : appeler une fonction native avec un mauvais nombre d'arguments ou faire un calcul sur un tableau arrête désormais l'exécution. Les versions suivantes ajoutent des dépréciations, comme les propriétés dynamiques en 8.2, qui remplissent les journaux sans bloquer le site. Pour savoir où vous en êtes, l'écran Santé du site, dans le menu Outils, indique la version PHP utilisée et signale si elle est dépassée.

Un écran blanc un lundi matin : le plugin de réservation abandonné

Le site du domaine, livré par nos soins quatre ans plus tôt, propose trois formules de visite, du tour du chai à l'atelier d'assemblage, réservables en ligne avec un acompte. Tout reposait sur une extension de réservation dont la dernière mise à jour datait de 2021. Elle tournait sans bruit en PHP 7.4. En PHP 8.2, elle est devenue le cas d'école du plugin incompatible PHP 8 : erreur fatale dès le premier chargement. Chargée sur toutes les pages, elle provoquait la page blanche WordPress sur tout le site. WordPress avait bien envoyé son email de mode de récupération, mais à la même adresse oubliée, celle d'un ancien stagiaire. Premier geste : revenir en arrière. L'hébergeur proposait encore PHP 7.4 pour quelques semaines, et le site est revenu en ligne une quarantaine de minutes après notre intervention. Deuxième geste : comprendre. Le journal d'erreurs pointait une fonction supprimée en PHP 8.0, appelée au cœur de l'extension. Corriger nous-mêmes ce code était tentant, mais patcher une extension morte, c'est en devenir le mainteneur, sans jamais recevoir de correctif de sécurité. Nous avons donc monté un site de test WordPress, copie conforme de la production passée en PHP 8.2, et remplacé l'extension par une solution de réservation maintenue. Créneaux, tarifs et environ 600 réservations ont été repris, puis le paiement de l'acompte testé de bout en bout. Le mercredi suivant, à 7 h 30, le site basculait en PHP 8.2 sans incident. Le passage en 8.3 est déjà calé avant la fin de l'année.

Comment savoir si une extension WordPress est compatible PHP 8 ?

Le second cas est plus serein, parce qu'il a été préparé. Une association culturelle, qui gère adhésions et billetterie sur WordPress, nous a sollicités quand son hébergeur a annoncé la fin de PHP 7.4 pour le trimestre suivant. Huit ans et trois webmasters bénévoles successifs avaient laissé 31 extensions installées. Avant de toucher à PHP, nous les avons auditées une par une. Sert-elle encore, et sur quelle page ? Quand a-t-elle été mise à jour pour la dernière fois ? Au-delà d'un an sans nouvelle version, la prudence s'impose. Jusqu'à quelle version de WordPress a-t-elle été testée ? Le répertoire officiel signale d'ailleurs celles qui n'ont pas été testées avec les trois dernières versions majeures. Son support répond-il encore ? Et surtout, WordPress fait-il désormais la même chose nativement, avec ses blocs ou son plan de site XML intégré ? Verdict : 9 extensions supprimées, dont deux désactivées depuis des années, un second outil SEO qui doublonnait le premier et un générateur de plan de site devenu inutile. Quatre autres ont été remplacées, dont le formulaire de contact et le bandeau cookies, tous deux abandonnés. Les 18 dernières, à jour et maintenues, ont été conservées telles quelles. Nous n'avons pas confié ce tri à un scanner automatique : l'outil de vérification de compatibilité le plus connu n'est plus maintenu et s'arrête à PHP 8.0. Le vrai test, c'est le site lui-même, sur une copie. Après deux jours de vérifications, l'association est passée en PHP 8.3, avec 22 extensions au lieu de 31 et sans une seule régression signalée.

Comment mettre à jour PHP sans casser WordPress ?

De ces deux histoires, nous avons tiré un protocole que nous appliquons à chaque mise à jour PHP WordPress. Tout commence par une copie de test : fichiers et base de données dupliqués sur un sous-domaine protégé par mot de passe et exclu de l'indexation, réglé sur la version PHP visée. Sur cette copie, nous activons le journal d'erreurs avec les constantes WP_DEBUG et WP_DEBUG_LOG, en laissant WP_DEBUG_DISPLAY désactivé : les erreurs s'écrivent dans un fichier debug.log au lieu de s'afficher à l'écran. Nous relisons ce fichier après chaque série de tests, y compris les simples dépréciations, qui annoncent les ennuis de la version suivante. Les tests suivent les parcours qui comptent pour l'activité : envoyer un formulaire et vérifier que l'email arrive, réserver un créneau, payer jusqu'à la confirmation, modifier une page dans l'éditeur, laisser tourner les tâches planifiées. Une fois la copie propre, vient la production : juste avant la bascule, fichiers et base de données sont sauvegardés et stockés hors du serveur. Le retour arrière est écrit à l'avance : qui remet l'ancienne version de PHP, comment restaurer, en combien de temps. La bascule se fait à une heure calme, un mardi ou un mercredi tôt le matin, jamais un vendredi soir ni la veille d'un week-end de dégustations. Nous vérifions enfin que l'email d'administration est bien lu, pour ne pas manquer l'alerte du mode de récupération. Sur les sites que nous hébergeons, les sauvegardes automatisées sont incluses et l'environnement de staging fait partie des options de notre offre d'hébergement et d'infogérance, ce qui rend ce protocole presque routinier.

Après la mise à jour : garder un WordPress sain

Une migration réussie ne protège que jusqu'à la prochaine. Pour qu'elle reste un non-événement, la maintenance WordPress repose sur trois habitudes. La première est une routine de mises à jour : extensions, thème et cœur chaque mois, avec un passage préalable sur la copie de test pour les versions majeures. La deuxième est la sobriété : chaque nouvelle extension doit justifier sa place, et celles qui ne servent plus partent, parce qu'une extension désactivée mais présente reste du code à surveiller. La troisième est la surveillance : une sonde de disponibilité qui prévient en cas de panne, un œil régulier sur le journal d'erreurs et sur l'écran Santé du site, et la prochaine fin de vie de PHP notée dans l'agenda plutôt que découverte dans un email d'hébergeur. Si le site montre des signes plus inquiétants, comptes administrateurs inconnus, pages de spam ou redirections étranges, changer de version de PHP ne suffira pas : il faut d'abord nettoyer le WordPress piraté et repartir d'une base saine. Un WordPress bien tenu n'est pas condamné à la lenteur pour autant : notre étude de cas sur le site du restaurant Backto fait état d'un score Lighthouse mobile entre 82 et 88 et d'un LCP autour de 2,1 secondes sur la page d'accueil. Nous assurons cette maintenance au temps passé, selon nos tarifs de développement et de maintenance. Le domaine viticole, lui, nous a confié la suite.