'fields' => 'ids' — ce simple argument, ajouté à un tableau de paramètres WP_Query, change profondément ce qui transite dans la mémoire du serveur lors d’une recherche interne. Par défaut, une requête de recherche standard construit un objet WP_Post complet pour chaque résultat, avec l’ensemble de son contenu, ses métadonnées chargées à la demande et parfois des champs personnalisés sensibles jamais destinés à quitter le contexte d’administration. Cette recette ne traite pas de l’indexation par un moteur de recherche externe, mais de la construction de la recherche interne elle-même.
Le problème observé
Une fonction de recherche interne, construite pour alimenter une barre de recherche en autocomplétion, interrogeait WP_Query sans restriction de champs et transmettait ensuite l’ensemble des objets trouvés à une fonction de formatage côté client via une réponse JSON. Un examen de la réponse réseau, dans les outils de développement du navigateur, révélait des champs personnalisés jamais affichés à l’écran, dont un identifiant interne de fournisseur et un statut de marge commerciale associés à certains produits.
Le snippet corrigé
function domaine_rechercher_produits($terme) {
$requete = new WP_Query(array(
's' => sanitize_text_field($terme),
'post_type' => 'produit',
'post_status' => 'publish',
'fields' => 'ids',
'posts_per_page' => 15,
));
return array_map('domaine_formater_resultat_public', $requete->posts);
}
function domaine_formater_resultat_public($id_produit) {
return array(
'titre' => get_the_title($id_produit),
'lien' => get_permalink($id_produit),
'image' => get_the_post_thumbnail_url($id_produit, 'thumbnail'),
);
}
Avec 'fields' => 'ids', la requête ne renvoie plus qu’un tableau d’identifiants numériques. La fonction de formatage récupère ensuite explicitement, un par un, les seuls champs destinés à l’affichage public, sans jamais charger ni transmettre l’objet complet du produit avec ses métadonnées internes.
Les variantes utiles de fields
| Valeur de fields | Ce qui est renvoyé | Cas d’usage typique |
|---|---|---|
'ids' | Tableau d’identifiants numériques | Recherche, filtrage, comptage |
'id=>parent' | Identifiants associés à leur parent | Construction d’arborescences |
| Valeur par défaut (absente) | Objets WP_Post complets | Affichage détaillé d’un article ou d’une page unique |
Le gain de performance, un bénéfice secondaire mais réel
Au-delà de la réduction de l’exposition de données, cette approche allège sensiblement la charge mémoire et le temps de réponse d’une recherche portant sur un grand nombre de résultats, puisque WordPress n’a plus à hydrater chaque objet complet avant que le code applicatif ne les filtre. Sur un catalogue de plusieurs milliers de produits, la différence se mesure directement dans le temps de réponse de l’autocomplétion.
Vérifier ce qui part réellement au client
Réduire les champs renvoyés par WP_Query ne suffit pas si la fonction de formatage qui suit continue, par erreur, à ressortir des métadonnées via get_post_meta() sans filtrage. Chaque fonction de formatage destinée à une réponse publique doit lister explicitement les champs autorisés, plutôt que de renvoyer un tableau construit par copie partielle d’une structure plus large.
Un réflexe à généraliser à d’autres recherches
Cette même logique s’applique à toute fonctionnalité de recherche ou de filtrage exposée publiquement : recherche de contacts dans un annuaire, filtrage de rendez-vous disponibles, suggestion de contenus liés. Dès qu’une requête WP_Query alimente une réponse destinée à un visiteur non authentifié, la question du périmètre de champs renvoyés mérite d’être posée avant celle de la performance.
En résumé
Le paramètre fields de WP_Query n’est pas qu’une optimisation technique : c’est un outil de réduction de surface d’exposition. Limiter une recherche interne à des identifiants, puis reconstruire manuellement une réponse restreinte aux seuls champs destinés à l’affichage, referme une fuite de métadonnées souvent invisible tant qu’on ne va pas inspecter la réponse réseau réelle.
