PHP 8 et thèmes WordPress : ce qui casse en migration, retour d’expérience

Depuis que WordPress 5.6 a annoncé la compatibilité avec PHP 8 en décembre dernier, plusieurs clients m’ont demandé de préparer la bascule de leurs hébergements. Sur le papier, le cœur de WordPress est prêt. Dans la pratique, ce sont les thèmes et les extensions tierces qui posent problème, souvent à cause de pratiques de code datant de PHP 5.

Ce billet est un retour d’expérience concret sur les migrations que j’ai menées ces dernières semaines : les erreurs les plus fréquentes rencontrées, pourquoi elles surviennent, et la méthode que j’utilise désormais pour tester un thème avant de basculer un site en production sur PHP 8.

Les arguments nommés, source d’erreurs fatales inattendues

PHP 8 introduit les named arguments, qui permettent d’appeler une fonction en précisant le nom des paramètres plutôt que leur ordre. C’est une avancée bienvenue, mais elle a un effet de bord redoutable : le nom des paramètres dans la déclaration d’une fonction devient une partie de son contrat public, même si le développeur n’a jamais prévu que les appelants l’utilisent ainsi.

J’ai vu plusieurs extensions renommer un paramètre entre deux versions mineures — un simple $id devenu $post_id — provoquant une erreur fatale chez tous les thèmes qui appelaient cette fonction avec des arguments nommés. Ce n’était pas un problème sous PHP 7, où seul l’ordre comptait.

Le typage strict qui remonte des bugs anciens

PHP 8 est beaucoup plus strict sur les comparaisons et les conversions de type entre chaînes et nombres. Un code qui « fonctionnait par accident » sous PHP 7 échoue désormais franchement. Exemple typique rencontré sur un thème e-commerce :

// Sous PHP 7, "10" == "10abc" pouvait donner des résultats surprenants
// Sous PHP 8, la comparaison chaîne / nombre est corrigée
if ( 0 == "prix-invalide" ) {
    // Ce bloc s'exécutait par erreur sous PHP 7
    // Il ne s'exécute plus sous PHP 8, changeant le comportement métier
}

Ce genre de correction est une bonne nouvelle pour la fiabilité du langage, mais elle peut modifier silencieusement la logique métier d’un thème mal écrit, sans qu’aucune erreur ne s’affiche pour le signaler clairement.

Les fonctions dépréciées à traquer

Plusieurs fonctions historiques disparaissent définitivement en PHP 8, après avoir été dépréciées depuis PHP 7.2 ou 7.4. Les plus fréquentes dans du vieux code de thème :

• create_function(), totalement supprimée, à remplacer par une fonction anonyme ou fléchée
• each(), supprimée, à remplacer par une boucle foreach
• Les extensions mysql_*, déjà absentes depuis PHP 7 mais parfois réintroduites via de vieux plugins wrappers
• Le passage par référence de variables non définies dans certains appels de fonctions internes, qui déclenche désormais des avertissements plus stricts

La fonction create_function() reste, de loin, la plus fréquente dans les thèmes premium achetés il y a cinq ou six ans et jamais mis à jour depuis.

Méthode de test avant de migrer un site en production

Voici la démarche que j’applique désormais systématiquement avant de faire basculer un client sur PHP 8 :

1. Cloner le site sur un environnement de recette identique (même version de WordPress, mêmes extensions actives)
2. Basculer cet environnement de recette sur PHP 8, jamais directement la production
3. Activer WP_DEBUG et WP_DEBUG_LOG pour capturer toutes les erreurs et avertissements sans les afficher aux visiteurs
4. Parcourir manuellement les parcours critiques : page d’accueil, articles, formulaires de contact, tunnel de commande si le site vend en ligne
5. Vérifier le fichier debug.log à la recherche d’erreurs de type Fatal error, Deprecated ou Warning liées au thème actif

Un outil comme PHP Compatibility Checker, disponible en extension WordPress, permet aussi un premier balayage automatisé du code du thème et des extensions avant même de toucher à l’environnement de recette.

Ne migrez jamais un client directement en production un vendredi après-midi. Passez systématiquement par une recette avec les logs activés pendant au moins une semaine de trafic réel avant de basculer, même si le thème « semble » compatible au premier coup d’œil.

En résumé

La compatibilité PHP 8 de WordPress 5.6 est une excellente nouvelle pour la performance et la sécurité du cœur, mais elle ne dispense pas d’un audit sérieux des thèmes et extensions tierces. Les erreurs les plus dangereuses ne sont pas toujours les erreurs fatales, faciles à repérer, mais les changements de comportement silencieux liés au typage strict. Prenez le temps de tester avant de migrer : c’est un investissement de quelques heures qui évite des nuits blanches en production.