wp core check-update ne suffit plus à lui seul pour anticiper une montée de version majeure : avec WordPress 7.0, qui exige PHP 8.4 comme seuil minimal d’exécution, la préparation d’un thème bloc hérité demande un audit de code, pas seulement une vérification de compatibilité de plugin.
Cette liste de contrôle rassemble les motifs de code les plus fréquemment rencontrés dans les thèmes blocs construits progressivement depuis plusieurs années, susceptibles de générer des avertissements ou des erreurs une fois le socle PHP relevé à 8.4. Elle ne couvre volontairement pas les nouveautés éditoriales apportées par WordPress 7.0 lui-même, ni la compatibilité des extensions tierces installées à côté du thème.
1. Les paramètres implicitement nullables
Le motif le plus fréquent, de loin, dans les thèmes blocs qui datent de plusieurs années : un paramètre typé avec une valeur par défaut à null, sans marquage explicite du type comme nullable.
// à corriger
function afficher_bloc( string $classe = null ) { /* ... */ }
// corrigé
function afficher_bloc( ?string $classe = null ) { /* ... */ }Une recherche globale dans le thème permet d’en dresser la liste avant toute montée réelle :
grep -rnE ": *(string|int|float|bool|array) *\\\$[a-zA-Z_]+ *= *null" wp-content/themes/mon-theme --include=*.php2. Les propriétés dynamiques non déclarées
Les classes PHP qui reçoivent des propriétés créées à la volée, sans déclaration préalable ni attribut #[AllowDynamicProperties], restent un motif fréquent d’avertissement hérité des versions précédentes de PHP. Le correctif consiste soit à déclarer explicitement chaque propriété utilisée, soit, quand la structure de la classe le justifie réellement, à ajouter l’attribut correspondant au-dessus de sa déclaration.
3. Les appels de fonctions dépréciées du cœur WordPress
Indépendamment de PHP lui-même, certaines fonctions du cœur WordPress marquées dépréciées depuis plusieurs versions continuent d’être appelées dans d’anciens thèmes. La commande WP-CLI suivante liste les appels à des fonctions dépréciées détectés lors de l’exécution d’une page :
wp eval-file audit-fonctions-depreciees.php --url=recette.mon-site.example4. Les comparaisons de type implicites sur des identifiants
Les comparaisons entre un identifiant récupéré en base (chaîne de caractères issue de $_GET ou d’un attribut de bloc) et une valeur entière, réalisées avec l’opérateur d’égalité simple plutôt que strict, restent un motif de bug latent, indépendamment de PHP 8.4, mais qui devient plus visible à mesure que les avertissements de conversion de type se multiplient dans les journaux.
5. Les classes qui redéfinissent une méthode sans attribut de contrôle
PHP 8.3 a introduit l’attribut #[\Override], qui permet de signaler explicitement qu’une méthode surcharge une méthode parente. Sans être une obligation stricte, son ajout facilite la détection d’erreurs de frappe dans le nom d’une méthode censée surcharger une méthode existante, un motif d’erreur silencieuse fréquent dans les classes de blocs personnalisés qui étendent une classe du cœur.
6. Les tests de compatibilité automatisés avant la montée réelle
Au-delà de la correction manuelle de ces motifs, un passage automatisé par un outil d’analyse statique reste la meilleure garantie de ne rien oublier :
- Installer PHPStan avec l’extension PHPCompatibility ciblant PHP 8.4 sur l’ensemble du thème.
- Corriger les erreurs bloquantes remontées avant toute erreur de niveau avertissement.
- Rejouer l’analyse sur un environnement de recette réel, avec un trafic représentatif pendant au moins quelques jours, avant la bascule en production.
- Documenter chaque correctif appliqué, pour que la prochaine montée de version majeure bénéficie de cette liste déjà défrichée.
Sur un thème bloc qui a traversé plusieurs versions majeures de WordPress sans réécriture complète, le vrai risque n’est jamais PHP 8.4 en lui-même, mais l’accumulation silencieuse de tolérances de versions précédentes qui n’ont jamais été nettoyées.
En résumé
Ces six points de contrôle ne prétendent pas remplacer un audit de code complet, mais couvrent les motifs les plus régulièrement rencontrés sur des thèmes blocs hérités au moment de relever le seuil minimal de PHP. Le détail des changements de comportement propres à PHP 8.4 reste consultable dans son guide de migration officiel, une lecture qui vaut largement le temps qu’elle prend avant toute montée en production d’un parc de thèmes.
