'sanitize_text_field' écrit comme chaîne de caractères dans un tableau associatif de callbacks fonctionne parfaitement, jusqu’au jour où une faute de frappe s’y glisse : 'saniti_text_field', par exemple, ne produit aucune erreur au chargement du fichier, seulement un avertissement au moment précis où ce callback est invoqué, souvent bien après l’écriture du code fautif.
Le problème : une référence de fonction qui ne se vérifie qu’à l’exécution
Un tableau de règles de sanitisation par type de champ, courant dans une extension qui traite des données de formulaire hétérogènes, ressemble typiquement à ceci avant refactoring :
$regles_sanitisation = [
'texte' => 'sanitize_text_field',
'email' => 'sanitize_email',
'url' => 'esc_url_raw',
'texte_riche' => 'wp_kses_post',
];
foreach ($champs as $nom => $valeur) {
$type = $types_champs[$nom] ?? 'texte';
$callback = $regles_sanitisation[$type];
$valeur_propre = $callback($valeur);
}
Si $regles_sanitisation contient une chaîne mal orthographiée, PHP ne signale rien avant l’appel effectif de $callback($valeur), et seulement si ce type de champ précis est réellement soumis lors d’un test. Un champ rarement utilisé peut ainsi transporter une faute de frappe non détectée pendant des mois, avec pour conséquence l’absence totale de sanitisation sur ce champ précis, plutôt qu’une erreur bloquante et visible.
Le snippet : la notation :: depuis PHP 8.1
PHP 8.1 introduit la syntaxe des callables de première classe, qui remplace une chaîne de caractères représentant une fonction par une référence directe à cette fonction, écrite nom_fonction(...). Cette référence est résolue au moment où le tableau est construit, et non plus seulement au moment de l’appel :
$regles_sanitisation = [
'texte' => sanitize_text_field(...),
'email' => sanitize_email(...),
'url' => esc_url_raw(...),
'texte_riche' => wp_kses_post(...),
];
foreach ($champs as $nom => $valeur) {
$type = $types_champs[$nom] ?? 'texte';
$callback = $regles_sanitisation[$type];
$valeur_propre = $callback($valeur);
}
Une faute de frappe sur le nom d’une fonction inexistante, comme saniti_text_field(...), provoque désormais une erreur fatale de type Error dès l’exécution de cette ligne précise, indépendamment du fait qu’un visiteur soumette ou non ce type de champ. Un outil d’analyse statique peut également signaler cette erreur avant même l’exécution, ce qu’une chaîne de caractères ne permettait pas de détecter avec la même fiabilité.
Ce que le comportement ne change pas
Le comportement d’exécution des fonctions sanitize_text_field(), sanitize_email() ou wp_kses_post() reste strictement identique après ce refactoring : la notation nom_fonction(...) ne fait que capturer une référence vers la fonction existante, sans en modifier la signature ni le corps. Le gain se situe uniquement au niveau de la détection d’erreur, pas du résultat produit par la sanitisation elle-même.
Variantes selon la structure du code existant
- Pour des méthodes de classe plutôt que des fonctions globales, la même syntaxe s’applique à une instance :
$this->nettoyerTexte(...), avec les mêmes bénéfices de détection anticipée. - Pour un tableau construit dynamiquement à partir d’une configuration externe, cette syntaxe ne s’applique pas directement, puisqu’elle nécessite que le nom de la fonction soit connu au moment de l’écriture du code, pas à l’exécution à partir d’une chaîne variable.
- Ce refactoring nécessite PHP 8.1 au minimum côté hébergement, ce qui doit être vérifié avant de le déployer sur un parc de sites hébergés à des versions PHP hétérogènes.
Vérifier la version PHP avant de généraliser le refactoring
Sur un parc de sites hébergés à des versions PHP différentes, la commande wp cli-info exécutée via WP-CLI renseigne la version PHP active sur chaque environnement, ce qui permet de prioriser ce refactoring sur les sites déjà passés à PHP 8.1 ou une version ultérieure, et de le reporter explicitement, avec une note dans le gestionnaire de tâches du projet, pour les sites qui restent sur une version antérieure.
Pour aller plus loin
Ce changement de syntaxe, mineur en apparence, illustre une tendance plus large des versions récentes de PHP : transformer des erreurs auparavant silencieuses ou tardives en échecs immédiats et explicites, ce qui réduit le temps passé à diagnostiquer un comportement de sanitisation manquant sur un champ précis.
