« Aujourd\\’hui » au lieu de « Aujourd’hui » : ce genre de résultat dans un champ enregistré en base de données a une explication précise, et elle ne vient presque jamais d’une faute de saisie de l’utilisateur.
Depuis ses tout débuts, WordPress applique un échappement automatique — historiquement lié à l’ancien réglage magic_quotes_gpc de PHP, retiré du langage depuis longtemps mais dont le comportement a été reproduit côté WordPress pour préserver la compatibilité des extensions existantes — sur les superglobales $_GET, $_POST, $_COOKIE et $_REQUEST. Concrètement, chaque apostrophe, guillemet ou antislash présent dans ces tableaux est automatiquement précédé d’un antislash supplémentaire avant même que le code du plugin ou du thème ne s’exécute.
Pourquoi cet échappement existe encore
À l’époque où PHP embarquait nativement l’option magic_quotes_gpc, celle-ci s’activait ou se désactivait selon la configuration du serveur, ce qui rendait le comportement des superglobales imprévisible d’un hébergement à l’autre. WordPress a choisi de neutraliser cette variabilité en appliquant systématiquement son propre échappement dès le chargement, indépendamment de la configuration serveur sous-jacente.
Ce choix garantit la cohérence, mais introduit une conséquence directe : toute valeur lue directement dans $_POST contient des antislashs supplémentaires qui n’existaient pas dans la saisie originale de l’utilisateur, et qui doivent être retirés avant tout traitement ou affichage.
wp_unslash() : retirer l’échappement avant de traiter
La fonction wp_unslash() a précisément ce rôle : parcourir une valeur — chaîne ou tableau, de façon récursive — et retirer l’antislash ajouté automatiquement par WordPress. Elle s’utilise systématiquement avant toute autre étape de traitement :
add_action( 'admin_post_enregistrer_avis', function () {
if ( ! isset( $_POST['commentaire'] ) ) {
return;
}
$commentaire = wp_unslash( $_POST['commentaire'] );
$commentaire = sanitize_textarea_field( $commentaire );
// $commentaire contient désormais "Aujourd'hui", pas "Aujourd\'hui".
update_post_meta( get_the_ID(), 'avis_client', $commentaire );
} );
L’ordre des opérations compte : appeler wp_unslash() avant sanitize_text_field(), jamais après. Une fonction de sanitization appliquée sur une valeur encore échappée risque de traiter l’antislash lui-même comme un caractère légitime du contenu, ce qui produit un résultat correct en apparence mais faux dans le détail.
Ce que wp_unslash() ne fait pas
Un piège classique consiste à croire que wp_unslash() sécurise une donnée. Ce n’est pas son rôle : elle ne fait que retirer un échappement technique ajouté par WordPress, sans filtrer ni valider quoi que ce soit sur le fond. Une valeur passée par wp_unslash() seule reste tout aussi dangereuse à afficher ou enregistrer telle quelle qu’avant.
wp_unslash()retire l’échappement automatique de WordPress, rien de plus.sanitize_text_field(),sanitize_textarea_field()ou une fonction équivalente nettoie ensuite le contenu selon son usage prévu.- L’échappement à l’affichage (
esc_html(),esc_attr()) reste une étape distincte, appliquée plus tard, au moment de la sortie.
Le cas des fonctions qui l’appliquent déjà
Certaines fonctions natives de WordPress, comme sanitize_text_field(), n’appliquent pas wp_unslash() en interne : le développeur doit l’appeler explicitement en amont. D’autres API de plus haut niveau, en revanche, s’en chargent déjà en coulisses. Il vaut mieux vérifier la documentation de la fonction utilisée plutôt que de supposer un comportement uniforme sur l’ensemble du cœur.
// Correct : unslash puis sanitization.
$titre = sanitize_text_field( wp_unslash( $_POST['titre'] ) );
// Incorrect : la sanitization s'applique sur une valeur encore échappée.
$titre = wp_unslash( sanitize_text_field( $_POST['titre'] ) );
Un oubli qui passe souvent inaperçu en développement
Sur un environnement local où les apostrophes sont rares dans les jeux de test, cet oubli peut rester invisible pendant des semaines. Il refait surface en production, dès qu’un vrai visiteur saisit un nom composé, un avis client contenant une négation, ou tout texte un peu plus naturel que les données de démonstration habituelles.
Sur tout formulaire qui traite une superglobale, vérifier la présence de
wp_unslash()avant la fonction de sanitization mérite une ligne dédiée dans la check-list de relecture de code.
En résumé
Cet échappement automatique des superglobales est une particularité propre à WordPress, absente de PHP en tant que tel depuis longtemps. Le réflexe à retenir est simple : wp_unslash() d’abord, sanitization ensuite, jamais l’inverse. Ce détail, invisible tant qu’aucune apostrophe ne traîne dans les données de test, redevient très visible dès qu’un vrai utilisateur tape du texte naturel dans un formulaire.
