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

> Un message d'erreur précis lié à une fonction du thème bloc appelée avec un type désormais invalide, après une montée vers PHP 8.2.

- Auteur : WordPress Développement
- Publié le : 2023-08-21
- Mis à jour le : 2023-08-21
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/php-82-editeur-site-erreur-migration/

## L’essentiel

- str_contains() reçoit null au lieu d'une chaîne
- Cause réelle : une meta non renseignée sur d'anciens articles
- Correctif par valeur par défaut, pas par suppression du typage strict

`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, '<!--more-->' )`.

## 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.

> L'essentiel à retenir : str_contains() reçoit null au lieu d'une chaîne ; Cause réelle : une meta non renseignée sur d'anciens articles ; Correctif par valeur par défaut, pas par suppression du typage strict

```
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, '<!--more-->' ) ) {
        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, '<!--more-->' ) ) {
        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.