WordPress 7.0 relève le seuil minimal de PHP à la version 8.4, sortie en novembre 2024. Pour un thème hérité, construit et maintenu depuis plusieurs années sans jamais avoir subi d’audit de compatibilité approfondi, ce relèvement de seuil transforme plusieurs habitudes de code tolérées jusqu’ici en erreurs fatales bloquantes. Cette check-list ne traite ni les nouveautés éditoriales de WordPress 7.0, ni la migration des extensions tierces installées sur le site : uniquement les motifs de code PHP du thème lui-même à corriger avant la bascule.
1. Rechercher les propriétés dynamiques implicites
Depuis PHP 8.2, l’assignation d’une propriété non déclarée sur un objet standard génère une dépréciation ; PHP 8.4 durcit encore ce comportement dans certains contextes internes. Un thème qui étend des classes du cœur WordPress en assignant des propriétés « à la volée » doit désormais déclarer explicitement ces propriétés.
// À corriger
class Mon_Widget_Personnalise extends WP_Widget {
public function construire() {
$this->options_supplementaires = array(); // propriété non déclarée
}
}
// Corrigé
class Mon_Widget_Personnalise extends WP_Widget {
private array $options_supplementaires = array();
public function construire() {
$this->options_supplementaires = array();
}
}La commande grep -rn '\$this->[a-z_]* =' wp-content/themes/mon-theme/ permet de repérer rapidement les candidats à vérifier manuellement, en croisant chaque résultat avec la déclaration de classe correspondante.
2. Vérifier les fonctions définitivement supprimées
Plusieurs fonctions dépréciées de longue date ont franchi, au fil des versions de PHP, le cap de la suppression pure et simple plutôt que du simple avertissement. Un audit doit vérifier explicitement l’absence de ces motifs dans le code du thème : create_function(), déjà supprimée depuis PHP 8.0, ou l’usage de accolades pour l’accès aux caractères d’une chaîne ($chaine{0}), supprimé encore plus tôt.
3. Contrôler le typage strict des paramètres de fonctions du cœur
PHP 8.4 renforce la vérification de type sur certains appels internes. Un thème qui passe un null implicite là où une chaîne de caractères est attendue, pratique tolérée sur d’anciennes versions de PHP, déclenchera désormais une dépréciation, voire une erreur selon le contexte d’appel.
// À risque : $valeur peut être null si le champ personnalisé n'existe pas
echo strtoupper( get_post_meta( get_the_ID(), 'sous_titre', true ) );
// Sécurisé
echo strtoupper( get_post_meta( get_the_ID(), 'sous_titre', true ) ?: '' );4. Repérer les appels à des hooks et fonctions dépréciés du cœur WordPress
- Rechercher les appels à
create_function()utilisés comme callback de hook - Vérifier l’absence d’utilisation de
each(), supprimée depuis longtemps de PHP - Confirmer qu’aucun appel direct à des fonctions marquées
_deprecated_function()par le cœur WordPress ne subsiste, via une recherche dans les logs de débogage activés en environnement de test
5. Tester la sérialisation et la désérialisation d’options complexes
Un thème qui stocke des structures de données complexes via update_option() et les relit via maybe_unserialize() doit être testé explicitement sous PHP 8.4, certains changements de comportement sur la gestion des classes non trouvées lors de la désérialisation pouvant provoquer des erreurs silencieuses différentes de celles observées sur PHP 8.1 ou 8.2.
6. Lancer un audit statique automatisé avant tout test manuel
Avant de parcourir manuellement le code, un outil comme PHPCompatibility, exécuté via PHP_CodeSniffer avec la règle ciblant PHP 8.4, détecte automatiquement la majorité des motifs listés ci-dessus, avec un gain de temps considérable sur un thème volumineux.
vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.4 wp-content/themes/mon-theme/Ne migrez jamais un vieux thème vers un nouveau seuil de PHP sans faire tourner d’abord un audit statique automatisé. Le gain de temps par rapport à une relecture manuelle intégrale se compte en heures, pas en minutes, sur un thème de plusieurs années.
Pour aller plus loin
Cette check-list couvre les motifs les plus fréquemment rencontrés lors d’audits de compatibilité PHP sur des thèmes hérités, mais elle ne dispense jamais d’une phase de test complète en environnement de préproduction avant la bascule effective vers WordPress 7.0. Un audit statique élimine l’essentiel des erreurs fatales prévisibles ; seul un test fonctionnel réel, sur des scénarios représentatifs de l’usage du site, confirme qu’aucune régression comportementale plus subtile n’a été introduite par ce relèvement de seuil.
