Sur une archive qui affiche des centaines de lignes, chaque appel superflu s’additionne. Charger un objet WP_Post complet — avec son contenu, son extrait, ses métadonnées implicites — pour n’en lire que le titre est un gaspillage facile à éviter avec get_post_field().
Cette fonction native accepte un nom de champ de la table wp_posts et un identifiant d’article, et retourne uniquement la valeur demandée. Contrairement à get_the_title(), elle ne passe pas le résultat dans les filtres d’affichage habituels, ce qui la rend plus prévisible dans un contexte où le texte brut est nécessaire.
Quand la différence se voit
Dans une boucle qui construit un tableau de correspondance identifiant vers titre pour des centaines d’articles, appeler get_post() à chaque itération instancie un objet complet à chaque fois, même si une seule propriété est utilisée ensuite. get_post_field() évite cette charge en n’exposant que le champ demandé.
$titre = get_post_field( 'post_title', $id_article );
$statut = get_post_field( 'post_status', $id_article );
$auteur_id = get_post_field( 'post_author', $id_article );
Chacun de ces appels s’appuie en réalité sur le cache d’objets interne de WordPress : si l’article a déjà été chargé une fois dans la requête courante, aucune nouvelle requête SQL n’est déclenchée. Le gain réel dépend donc largement du contexte, mais l’appel reste toujours plus léger à écrire et à lire qu’un get_post() suivi d’un accès de propriété.
get_post_field face à get_the_title
| Fonction | Passe par les filtres d’affichage | Usage typique |
|---|---|---|
get_the_title() | Oui (the_title, formatage) | Affichage front-end classique |
get_post_field( 'post_title', $id ) | Non | Comparaison, export, traitement interne |
Cette absence de filtres est justement ce qui rend get_post_field() utile pour des traitements internes : comparer un titre brut à une valeur attendue dans un test, générer un export CSV, ou peupler un tableau de données destiné à un usage strictement interne où le HTML ajouté par certains filtres serait indésirable.
Un troisième paramètre souvent oublié
La fonction accepte un troisième argument, $context, qui contrôle l’échappement appliqué à la valeur retournée : raw, edit, db ou display. Par défaut, elle utilise le contexte display, qui applique déjà un échappement HTML de base sur certains champs.
- Pour un traitement strictement interne (comparaison, log), le contexte
rawévite tout échappement superflu. - Pour un affichage direct, le contexte par défaut suffit généralement.
- Un champ inexistant sur le type de contenu demandé retourne une chaîne vide, jamais une erreur PHP.
Ne pas confondre avec wp_list_pluck
get_post_field() cible un seul article identifié par son identifiant, tandis que wp_list_pluck() traite un tableau entier de résultats déjà chargés. Les deux se complètent : la première est adaptée à un accès ponctuel, la seconde à une transformation en masse.
Un repère utile en revue de code : si la variable qui suit un
get_post()n’est utilisée que pour lire une seule propriété, la ligne entière peut presque toujours être remplacée par unget_post_field()plus direct.
En résumé
Sur un site où les listes d’articles s’allongent avec le temps, remplacer les get_post() superflus par des get_post_field() ciblés est une optimisation à faible risque et à faible coût de mise en œuvre. Le gain n’est pas toujours spectaculaire isolément, mais il s’accumule sur les pages qui affichent le plus grand nombre de résultats.
