Paramètre implicitement nullable : le piège PHP 8.4 qui casse un thème bloc

Deprecated: Implicitly marking parameter $callback_secours as nullable is deprecated, the explicit nullable type must be used instead. Ce message apparaît dans les journaux dès la première visite du site après une montée de version vers PHP 8.4, sur un thème bloc jusque-là parfaitement stable.

Contrairement à un simple avertissement silencieux, celui-ci s’accompagne ici d’un comportement visible : la partie de template template-parts/carte-evenement.php, qui affiche une image de repli quand aucune image mise en avant n’est définie, cesse purement et simplement de s’afficher sur certains événements, provoquant un trou visuel dans la grille de la page d’accueil.

Symptôme : une fonction de repli qui ne se déclenche plus

Le code en cause déclare une méthode de classe utilisée par le template pour fournir une image par défaut :

class Carte_Evenement {
    public function afficher_image( string $callback_secours = null ) {
        if ( has_post_thumbnail() ) {
            the_post_thumbnail( 'carte' );
        } elseif ( null !== $callback_secours ) {
            call_user_func( $callback_secours );
        }
    }
}

Sur les versions précédentes de PHP, déclarer un paramètre typé string avec une valeur par défaut à null était toléré, PHP interprétant implicitement le type comme nullable malgré l’absence du point d’interrogation. PHP 8.4 déprécie ce comportement, documenté précisément dans son guide de migration : le type doit désormais être explicitement marqué nullable pour que l’intention soit non ambiguë.

Diagnostic : localiser tous les paramètres implicitement nullables

Le journal d’erreurs, une fois WP_DEBUG_LOG activé, pointe précisément vers la ligne de déclaration de la méthode afficher_image(). Mais l’avertissement seul n’explique pas pourquoi l’image de repli ne s’affiche plus : une vérification complémentaire dans le code appelant révèle que la fonction passée en argument avait, entre-temps, été renommée dans une mise à jour antérieure du thème, sans que l’appel correspondant ne soit mis à jour. L’avertissement de dépréciation a eu le mérite de faire remonter, à l’occasion de la montée de version, un bug latent qui serait resté invisible sans lui.

Correctif : typer explicitement et corriger l’appel obsolète

La déclaration du paramètre est corrigée en premier lieu, pour faire taire l’avertissement de dépréciation :

public function afficher_image( ?string $callback_secours = null ) {

Puis l’appel réellement fautif est corrigé, en remplaçant le nom de fonction obsolète par le nom actuel de la fonction de repli définie dans functions.php :

echo '<div class="carte-evenement">';
( new Carte_Evenement() )->afficher_image( 'monclient_image_repli_evenement' );
echo '</div>';

Prévention : traiter chaque montée de PHP comme un audit

Ce type d’incident illustre un principe simple : un avertissement de dépréciation n’est presque jamais un problème en soi, mais souvent le signal d’un problème préexistant qui devient enfin visible. Avant toute montée de version majeure de PHP sur un parc de thèmes, quelques vérifications limitent le risque :

• Faire tourner un outil d’analyse statique (PHPStan avec l’extension PHPCompatibility, par exemple) sur l’ensemble du thème avant la montée réelle.
• Activer temporairement WP_DEBUG_LOG sur un environnement de recette recevant un trafic représentatif, pendant au moins quelques jours, avant de valider la montée en production.
• Grep systématique des paramètres typés avec une valeur par défaut à null, candidats évidents à ce type de dépréciation :

grep -rnE "function [a-zA-Z_]+\([^)]*: *(string|int|float|bool|array) *\\\$[a-zA-Z_]+ *= *null" wp-content/themes/mon-theme

Sur nos projets, chaque montée de version de PHP s’accompagne désormais d’une revue systématique du journal d’erreurs sur une période de recette d’au moins une semaine, jamais d’une simple bascule en production suivie d’une vérification visuelle rapide.

En résumé

Ce que PHP 8.4 a réellement révélé ici n’était pas un problème de compatibilité en soi, mais un bug de code mort masqué par une tolérance de typage désormais supprimée. Le correctif technique tient en un seul caractère ajouté au type du paramètre, mais le vrai travail a consisté à comprendre pourquoi l’avertissement s’accompagnait d’un symptôme visible. Le détail complet de cette dépréciation figure dans le guide de migration officiel vers PHP 8.4.