PHP 8.2 et l’éditeur de site : des templates qui échouent après montée

Deprecated: str_contains(): Passing null to parameter #1 ($haystack) of type string is deprecated. Voilà le message qui a envahi le journal d’erreurs le lendemain d’une montée de version PHP de 8.0 à 8.2 sur un site institutionnel utilisant l’éditeur de site. Le site restait accessible, mais certains templates d’archive affichaient un contenu tronqué à l’endroit précis où l’erreur survenait.

Ce billet détaille le diagnostic de cette dépréciation précise, liée à une fonction du thème bloc, et son correctif. Il ne couvre pas l’ensemble des dépréciations introduites par PHP 8.2 ni la migration des extensions tierces du site, deux sujets bien plus vastes qui mériteraient chacun leur propre traitement.

Le contexte de la montée de version

PHP 8.2 a durci le comportement de plusieurs fonctions de la bibliothèque standard vis-à-vis des paramètres de type null implicite, un usage toléré jusqu’à PHP 8.0 mais désormais signalé comme obsolète. Les fonctions str_contains(), str_starts_with() et leurs équivalentes sont concernées dès lors qu’on leur transmet une valeur null là où une chaîne de caractères est attendue.

Le thème bloc du site, écrit à l’origine pour PHP 7.4, contenait une quarantaine de fonctions utilitaires personnalisées enregistrées comme sources de liaison pour des blocs dynamiques. L’une d’elles calculait un résumé d’article en cherchant une balise de coupure via str_contains( $content, '

' ).

Localiser la fonction fautive

Le journal d’erreurs indiquait la ligne exacte, mais pas la donnée à l’origine du null. En ajoutant un point d’arrêt temporaire via error_log( var_export( $content, true ) ) juste avant l’appel litigieux, la cause est apparue : certains articles anciens, importés lors d’une migration antérieure, avaient un champ personnalisé resume_court jamais renseigné, retournant null plutôt qu’une chaîne vide lors de la lecture via get_post_meta() avec le paramètre $single à true sur une clé absente.

function wpm_get_resume_article( $post_id ) {
    $resume = get_post_meta( $post_id, 'resume_court', true );
    // $resume vaut '' normalement, mais peut être null
    // si la meta a été enregistrée avec une valeur explicitement null
    // par un ancien script d'import.
    if ( str_contains( $resume, '' ) ) {
        return wpm_extract_before_more( $resume );
    }
    return $resume;
}

Le correctif : sécuriser la valeur avant l’appel

Deux approches étaient possibles. La première, désactiver le rapport des dépréciations en production, aurait masqué le symptôme sans corriger la cause, et aurait laissé subsister le comportement erroné sur le contenu réellement tronqué. La seconde, plus saine, consiste à garantir un type string avant l’appel, avec une valeur par défaut explicite.

function wpm_get_resume_article( $post_id ) {
    $resume = (string) get_post_meta( $post_id, 'resume_court', true );

    if ( str_contains( $resume, '' ) ) {
        return wpm_extract_before_more( $resume );
    }
    return $resume;
}

Ce correctif, appliqué aux quarante fonctions utilitaires du thème par une recherche systématique des usages de str_contains(), str_starts_with() et str_ends_with(), a éliminé les dépréciations et, surtout, corrigé l’affichage tronqué des résumés sur les archives concernées.

Vérifier avant la montée, pas après

• La commande wp eval 'phpinfo();' permet de vérifier rapidement la version PHP réellement active après une montée, un détail parfois différent de la configuration attendue sur un hébergement mutualisé.
• Activer temporairement WP_DEBUG et WP_DEBUG_LOG sur un environnement de recette avant toute montée de version, pour repérer les dépréciations sans exposer les visiteurs du site en production.
• Auditer en priorité les fonctions manipulant des metas ou des champs personnalisés, terrain le plus fréquent de valeurs null inattendues sur un site ancien.

Une dépréciation PHP qui n’affecte « que » le journal d’erreurs cache parfois un vrai bug fonctionnel resté invisible jusque-là.

Notre verdict

Ce cas illustre une règle simple pour toute montée de version PHP sur un site en éditeur de site : les fonctions de source de liaison et les callbacks de blocs dynamiques méritent une vérification systématique, car elles manipulent souvent des données de contenu ancien dont le typage réel s’écarte des attentes du code récent. Un correctif de typage explicite, plutôt qu’un contournement de la dépréciation, évite de reproduire la même alerte à la prochaine montée de version.