Un client juridique peu enclin à refondre son site n’a pas besoin d’entendre parler de PHP 8.4 tant que rien ne casse visiblement. Le problème, avec les dépréciations introduites par cette version sortie en novembre 2024, c’est justement qu’elles ne cassent rien de façon spectaculaire : elles produisent des avertissements silencieux, invisibles pour un visiteur, mais qui s’accumulent dans les journaux d’erreurs jusqu’à devenir de vraies erreurs fatales dans une future version de PHP.
Ce qui a été trouvé dans functions.php
Le thème de ce cabinet de notaires date de plusieurs années et n’a jamais été retouché en profondeur. Une revue ciblée de functions.php après la montée de version PHP a permis d’identifier trois usages concernés par les dépréciations de PHP 8.4, aucun d’entre eux ne provoquant d’erreur fatale immédiate, mais tous générant des notices dans les journaux à chaque exécution du gabarit concerné.
Point 1 — Propriétés dynamiques non déclarées
Une classe utilitaire du thème assignait des propriétés à la volée sans les déclarer au préalable, un usage déjà déprécié depuis PHP 8.2 mais dont le traitement se durcit encore dans les versions suivantes. La correction consiste à déclarer explicitement chaque propriété utilisée, ou à ajouter l’attribut #[AllowDynamicProperties] sur la classe si la refonte complète n’est pas envisageable à court terme.
Point 2 — Fonctions de tableau appelées avec des arguments implicitement nullables
Plusieurs appels de fonctions du thème passaient null à des paramètres typés sans déclarer explicitement leur nullabilité, un usage que PHP 8.4 traite désormais avec un avertissement de dépréciation plus strict. Dans functions.php, une fonction de mise en forme de date recevait parfois une valeur nulle sans que son paramètre ne soit déclaré ?string :
// Avant : génère une dépréciation en PHP 8.4
function wpm_formater_date( string $date ) {
return $date ? date_i18n( 'j F Y', strtotime( $date ) ) : '';
}
// Après : nullabilité explicite
function wpm_formater_date( ?string $date ) {
return $date ? date_i18n( 'j F Y', strtotime( $date ) ) : '';
}
Point 3 — Une fonction de tableau dépréciée dans son usage historique
Le thème utilisait encore une construction ancienne pour trier un tableau d’articles avant affichage, avec un rappel de fonction passé sous une forme que PHP considère désormais comme obsolète dans son traitement interne des types de callables. Remplacer ce rappel par une fonction fléchée explicite a supprimé la notice sans changer le comportement du tri.
Ce qui n’a heureusement pas posé de problème
- Aucun appel direct à une fonction totalement supprimée de PHP, seulement des usages dépréciés mais encore fonctionnels
- Le cœur WordPress lui-même, déjà compatible PHP 8.4 depuis plusieurs versions
- Les extensions tierces utilisées par ce site, toutes maintenues et déjà à jour vis-à-vis de cette version
Checklist à suivre pour un thème ancien
- Activer temporairement l’affichage des notices et avertissements sur un environnement de test, jamais en production
- Parcourir
functions.phpet les gabarits à la recherche de propriétés de classe assignées sans déclaration préalable - Vérifier la nullabilité des paramètres de chaque fonction utilitaire du thème appelée avec des valeurs potentiellement nulles
- Rechercher les callables passés sous une forme de chaîne de caractères plutôt qu’une syntaxe moderne
- Surveiller les journaux d’erreurs du serveur pendant au moins une semaine après la montée de version, avant de considérer le thème comme conforme
Une dépréciation qui ne casse rien aujourd’hui reste une dette qui se réglera, tôt ou tard, au moment le moins pratique possible.
En résumé
Un thème ancien peut cohabiter avec PHP 8.4 sans réécriture complète, à condition de traquer méthodiquement les usages dépréciés plutôt que d’attendre qu’ils deviennent des erreurs fatales dans une future version. Pour ce cabinet de notaires, ce travail a représenté moins d’une journée d’intervention, largement suffisant pour repousser sereinement l’échéance d’une refonte plus profonde du thème.
