PHP 8.3 et l’éditeur de site : des templates qui déclenchent des warnings

Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated. Voilà le message qui remonte dans les logs PHP dès la première visite du site, juste après une montée de version qui saute plusieurs paliers d’un coup : PHP 7.4 vers 8.3, sans étape intermédiaire.

Le site tourne sur un thème bloc maison, avec un template front-page.html qui s’appuie sur une fonction de rendu déclarée dans functions.php. Rien de spectaculaire à l’écran : la page s’affiche normalement. Mais chaque chargement ajoute une ligne dans le journal d’erreurs, et l’hébergeur commence à envoyer des alertes de quota d’espace disque.

Symptôme : un avertissement silencieux mais persistant

Le template appelle un bloc personnalisé qui affiche un slogan configurable depuis le Customizer (conservé pour compatibilité avec un ancien réglage). Le code source de la fonction de rendu ressemble à ceci :

function afficher_slogan_hero() {
    $slogan = get_theme_mod( 'slogan_hero' );
    echo esc_html( trim( $slogan ) );
}

Sur PHP 7.4, passer null à trim() ne provoquait qu’une conversion implicite silencieuse. Sur PHP 8.1 déjà, ce comportement était marqué comme déprécié ; mais tant que le site restait sur une version antérieure, l’avertissement ne s’affichait jamais dans les journaux consultés par l’équipe. En sautant directement à 8.3, cette dépréciation devient soudain visible, à chaque page qui n’a pas de valeur enregistrée pour slogan_hero.

Diagnostic : remonter jusqu’à la valeur nulle

Le réflexe consiste d’abord à activer WP_DEBUG_LOG dans wp-config.php pour capturer la pile d’appels complète plutôt que de deviner. Le journal confirme que l’appel problématique vient bien de afficher_slogan_hero(), ligne 42 du fichier functions.php.

Un test rapide dans la console WP-CLI confirme l’hypothèse :

wp eval "var_dump( get_theme_mod( 'slogan_hero' ) );"
// NULL

Sur les sites où l’option n’a jamais été enregistrée en base (nouveaux environnements de recette, sites clonés sans les options du Customizer), get_theme_mod() retourne effectivement null lorsqu’aucune valeur par défaut n’est fournie en second argument. Le bug n’est donc pas dans trim(), mais dans l’absence de garde-fou côté thème.

Correctif : sécuriser l’entrée avant de la traiter

Deux options s’offrent ici. La première consiste à fournir une valeur par défaut directement à get_theme_mod(), ce qui est la pratique recommandée par la documentation de l’API :

function afficher_slogan_hero() {
    $slogan = get_theme_mod( 'slogan_hero', '' );
    echo esc_html( trim( $slogan ) );
}

La seconde, complémentaire, consiste à caster explicitement la valeur en chaîne avant de la manipuler, ce qui protège contre tous les appels similaires ailleurs dans le thème :

$slogan = (string) get_theme_mod( 'slogan_hero', '' );

Ce correctif à une ligne suffit à faire disparaître l’avertissement, sans toucher au rendu visuel. Le test de non-régression se limite à recharger la page d’accueil et vérifier que le journal PHP reste silencieux.

Prévention : chasser les valeurs nullables du thème

Ce genre de dépréciation ne concerne jamais un seul appel isolé. Une recherche globale dans le thème permet de repérer les autres candidats :

• Toute utilisation de get_theme_mod(), get_option() ou get_post_meta() passée directement à une fonction de chaîne (trim(), strtolower(), htmlspecialchars()).
• Les attributs de bloc optionnels récupérés via $attributes['texte'] ?? null puis réutilisés sans vérification.
• Les champs ACF ou Meta Box lus directement dans un render_callback sans valeur de repli.

La commande wp-cli suivante aide à lister rapidement les fonctions à risque dans un thème avant une montée de version :

grep -rn "get_theme_mod(" wp-content/themes/mon-theme --include=*.php

Sur nos projets, on ajoute désormais systématiquement une valeur par défaut à chaque get_theme_mod() et get_option() du thème, même quand elle semble redondante : c’est une ligne qui coûte rien et qui évite des heures de traque plus tard.

En résumé

Ce warning n’est pas une régression de PHP 8.3, mais la mise en lumière tardive d’un comportement déjà déprécié depuis PHP 8.1. Le vrai problème n’était pas visible parce que la montée de version s’est faite en un seul bond, sans passer par les paliers intermédiaires qui auraient permis de le détecter plus tôt. La documentation officielle de PHP liste précisément ces changements de comportement dans son guide de migration vers PHP 8.3, une lecture à ne pas sauter avant toute montée de version d’un parc de thèmes blocs.