Passer un site WordPress en PHP 8.5, sans écran blanc.

Pourquoi ne pas rester sur l’ancienne version ?

Une version de PHP qui n’est plus suivie ne reçoit plus de correctifs de sécurité. PHP 7.4 n’en reçoit plus depuis novembre 2022, PHP 8.0 depuis novembre 2023, PHP 8.1 depuis décembre 2025. Chaque faille découverte depuis reste ouverte, et les sites WordPress sont scannés automatiquement par des robots, pas seulement les gros.

Il y a aussi un risque plus immédiat : les hébergeurs finissent par retirer les anciennes versions. Le jour où ils le font, le site s’affiche en erreur du jour au lendemain, souvent sans que personne n’ait lu l’e-mail de prévenance.

Où ça casse vraiment

Presque jamais dans WordPress lui-même. Les points de rupture, par ordre de fréquence :

• Les plugins abandonnés : plus de mise à jour depuis deux ans ou plus. Ils contiennent du code que PHP 8 ne comprend plus.
• Le thème, surtout s’il est sur mesure : du code dans functions.php qui lit des clés de tableau absentes, ou qui passe null à des fonctions comme trim().
• Les anciens constructeurs de pages et sliders, très gourmands en code ancien.
• Les extensions de paiement et de livraison sur une boutique WooCommerce.
• Les propriétés dynamiques (avertissement « Creation of dynamic property » depuis PHP 8.2) dans des classes de plugins anciens.

La méthode, étape par étape

1. Sauvegarde complète : fichiers et base de données, téléchargée hors de l’hébergeur. Vérifiez qu’elle se restaure.
2. Copie de test sur un sous-domaine privé (protégé par mot de passe et en noindex), avec la même base de données copiée.
3. Tout mettre à jour d’abord : WordPress, thème et plugins, tant que vous êtes encore sur l’ancienne version de PHP. Une partie des problèmes disparaît ici.
4. Activer le journal d’erreurs sur la copie (voir ci-dessous).
5. Passer la copie en PHP 8.5 dans le panel de l’hébergeur.
6. Parcourir les pages clés : accueil, articles, formulaires de contact, recherche, espace client, et le tableau de bord. Puis lire le journal.
7. Corriger ou remplacer ce qui est signalé, puis recommencer jusqu’à ce que le journal reste vide.
8. Bascule : sauvegarde juste avant, changement de version sur le site réel à une heure calme, nouvelle lecture des journaux.

Voir les erreurs sans les montrer aux visiteurs

Sur la copie de test, ajoutez ceci dans wp-config.php, avant la ligne « That’s all, stop editing » :

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

Les erreurs s’écrivent alors dans wp-content/debug.log, sans s’afficher sur les pages. Chaque ligne indique le fichier et le numéro de ligne fautifs, donc le plugin ou le thème responsable. Retirez ces lignes quand vous avez fini.

Un plugin n’est plus maintenu : que faire ?

C’est le cas le plus courant, et il y a quatre issues :

• Chercher une version plus récente ou une reprise du projet par un autre développeur.
• Le remplacer par un plugin équivalent et suivi.
• Le corriger : un petit correctif suffit souvent. Je le documente pour qu’il ne soit pas écrasé à la prochaine mise à jour.
• Le supprimer : il arrive souvent qu’un plugin ne serve plus du tout. C’est alors la meilleure correction.

Le bon choix dépend de l’usage et du coût. Je vous le présente avant de commencer, pas après.

Cas particulier : une boutique WooCommerce

Quand le site vend, une panne coûte des ventes. En plus de la méthode ci-dessus :

• Testez une commande complète sur la copie, avec la passerelle de paiement en mode test.
• Vérifiez les e-mails de commande, la gestion du stock et les webhooks du paiement.
• Faites la bascule à l’heure la plus creuse de vos ventes, et surveillez les premières commandes réelles.

Questions fréquentes