« Pourquoi ce chemin ne correspond-il jamais, alors qu’il semble identique à l’œil nu ? » Cette question revient régulièrement dès qu’un code compare des chemins de fichiers récupérés de sources différentes : une constante WordPress, une valeur retournée par une bibliothèque tierce, un chemin saisi manuellement dans un réglage. Sur un hébergement Windows, ces chemins peuvent mélanger antislashs et slashs, rendant toute comparaison stricte imprévisible.
wp_normalize_path() existe précisément pour ce cas : elle uniformise un chemin donné en remplaçant systématiquement les antislashs par des slashs, quel que soit le système d’exploitation sous-jacent.
Ce que fait la fonction, précisément
Trois transformations successives : remplacement de tous les antislashs par des slashs, suppression des séparateurs doublés consécutifs à l’exception du préfixe réseau Windows éventuel, et suppression d’un slash final superflu s’il y en a un.
echo wp_normalize_path( 'C:\wamp64\www\mon-site\wp-content' );
// C:/wamp64/www/mon-site/wp-content
echo wp_normalize_path( '/var/www//mon-site/wp-content/' );
// /var/www/mon-site/wp-content
Le résultat est un chemin exploitable de façon identique quel que soit le système d’origine, un prérequis avant toute comparaison de type === ou strpos().
Un cas d’usage typique : vérifier qu’un fichier est bien dans wp-content
function fichier_dans_wp_content( $chemin ) {
$chemin = wp_normalize_path( $chemin );
$racine = wp_normalize_path( WP_CONTENT_DIR );
return 0 === strpos( $chemin, $racine );
}
Sans la normalisation préalable des deux côtés de la comparaison, ce test échouerait silencieusement sur un hébergement où WP_CONTENT_DIR contient des antislashs alors que le chemin fourni en contient des slashs, ou inversement.
Où WordPress l’utilise déjà en interne
- La classe
WP_Filesystem_Directnormalise systématiquement les chemins avant toute opération de lecture ou d’écriture. - Les fonctions de gestion des médias comparent des chemins de fichiers normalisés pour éviter les doublons lors d’un import.
- La documentation officielle sur developer.wordpress.org recommande explicitement cette fonction avant toute manipulation de chemin destinée à être comparée ou stockée.
Ne pas confondre avec l’échappement de chemin
wp_normalize_path() ne vérifie ni l’existence du fichier, ni la sécurité du chemin fourni : elle se contente d’uniformiser sa forme. Un chemin contenant une tentative de remontée de répertoire via ../ reste tel quel après normalisation, et doit être validé séparément si son origine n’est pas fiable.
Un repère simple à adopter en revue de code : dès qu’un chemin de fichier provient d’une source externe à la configuration du site — une valeur d’option, un import, une bibliothèque tierce — une normalisation systématique avant comparaison évite une classe entière de bugs difficiles à reproduire en local.
En résumé
Comparer des chemins de fichiers sans les normaliser au préalable fonctionne généralement en local, sur un poste de développement Unix, et échoue parfois silencieusement sur un hébergement mutualisé Windows plus rare mais toujours présent chez certains prestataires. wp_normalize_path() élimine ce risque à un coût quasi nul, une ligne à ajouter avant chaque comparaison de chemin sensible.
