WordPress et PHP 8.6 : comment préparer son hébergement avant la fin de support de PHP 8.4

Préparez votre site WordPress à PHP 8.6, mais ne basculez en production qu’après avoir vérifié sa disponibilité chez votre hébergeur et la compatibilité réelle du site. PHP 8.4 reçoit des correctifs actifs jusqu’au 31 décembre 2026, puis des correctifs de sécurité jusqu’au 31 décembre 2028 : vous disposez donc de temps pour tester.

Planifier la version cible

Le calendrier officiel distingue le support actif, qui comprend les corrections de bugs et de sécurité, du support de sécurité seul. Après le 31 décembre 2026, PHP 8.4 ne recevra plus de correctifs ordinaires ; cette échéance est un jalon de préparation, pas une obligation de migration immédiate.

À la date de préparation de cet article, PHP 8.6 n’est pas encore une version stable à déployer en production. Sa disponibilité dépendra du calendrier de l’hébergeur, de votre formule et de sa configuration.

Consultez le calendrier des versions PHP prises en charge, puis vérifiez auprès de l’hébergeur que PHP 8.6 peut être activé par site et qu’un retour vers une version stable reste possible. Contrôlez aussi la présence des extensions PHP nécessaires à WordPress et à vos plugins, comme cURL, DOM, Exif, imagick ou GD, intl, mbstring, mysqli et ZIP selon votre usage.

La page WordPress Configuration requise fournit un socle, sans garantir la compatibilité de votre installation. WooCommerce, un constructeur de pages ou une extension métier peuvent imposer leurs propres contraintes.

Tester avant la bascule

Testez sur une préproduction fidèle, avec la même version de WordPress, le même thème, les mêmes extensions et, autant que possible, une copie récente de la base de données. Mettez d’abord à jour les composants et relevez ceux qui sont abandonnés ou peu maintenus.

Activez les journaux d’erreurs : WP_DEBUG et WP_DEBUG_LOG permettent de consigner les erreurs dans un cadre de diagnostic maîtrisé.
Vérifiez les parcours critiques : formulaires, connexion, publication, recherche, paiement WooCommerce, espace client, e-mails et tâches planifiées.
Contrôlez WP-Cron, les imports, les sauvegardes et les webhooks, qui peuvent échouer sans rendre les pages publiques indisponibles.
Conservez les versions testées de PHP, WordPress, du thème, des extensions et des extensions PHP côté serveur.

Un outil comme Query Monitor peut aider à repérer des erreurs PHP et des requêtes anormales en préproduction, sans remplacer un test de charge. Si l’hébergeur ne propose pas encore PHP 8.6, privilégiez un environnement de test, des sauvegardes fiables et un support adapté plutôt qu’une disponibilité précoce de la version.

Déployer avec un retour arrière

Avant le changement, effectuez une sauvegarde complète des fichiers et de la base de données, puis vérifiez qu’elle peut être restaurée. Notre guide sur les sauvegardes immuables WordPress détaille les critères à examiner chez un hébergeur.

Programmez la bascule pendant une période de faible activité, videz les caches applicatifs et CDN si nécessaire, puis rejouez les parcours critiques. Documentez qui remet la version PHP précédente, où restaurer la sauvegarde et quels contrôles confirment le retour du site.

Surveillez les journaux PHP et WordPress durant les heures suivantes. Une page blanche, une erreur 500, des commandes bloquées ou des e-mails non envoyés justifient un retour à la version précédente, suivi d’une analyse hors production.