# get_post_field pour lire un seul champ sans charger l’objet post complet

> Charger un objet WP_Post entier pour ne lire qu'un titre coûte plus cher qu'il n'y paraît sur une liste longue. Une fonction dédiée règle ce déséquilibre.

- Auteur : WordPress Développement
- Publié le : 2020-05-14
- Mis à jour le : 2020-05-14
- Catégorie : Astuces
- URL : https://www.wpmoderne.fr/tips/get-post-field-lire-champ-sans-post-complet/

## L’essentiel

- Lit un champ précis sans instancier tout l'objet WP_Post
- S'appuie sur le cache d'objets déjà chargé pour éviter une requête
- Se distingue de get_the_title par son absence de filtres d'affichage

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

> L'essentiel à retenir : Lit un champ précis sans instancier tout l'objet WP_Post ; S'appuie sur le cache d'objets déjà chargé pour éviter une requête ; Se distingue de get_the_title par son absence de filtres d'affichage

```
$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 un `get_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.