Le widget Posts d’Elementor Pro couvre déjà beaucoup de terrain avec son interface graphique : filtrage par catégorie, par taxonomie, par nombre d’articles, tri par date ou par titre. Mais dès qu’un client demande une règle plus fine — exclure les articles déjà mis en avant ailleurs sur la page, ou filtrer par une meta_query sur un champ ACF précis — l’interface atteint sa limite. C’est là qu’intervient le champ Query ID, une passerelle directe vers PHP trop peu connue.
Sur un site immobilier récent, nous avons utilisé ce mécanisme pour afficher, dans un widget Posts, uniquement les biens dont le champ ACF « statut » valait « disponible », une condition impossible à exprimer avec les seuls contrôles natifs du widget.
Le champ Query ID dans l’éditeur
Dans les réglages du widget Posts (ou Portfolio), l’onglet Query propose un champ texte libre nommé Query ID. Ce champ ne fait rien à lui seul : il sert uniquement d’identifiant que votre code PHP viendra reconnaître pour appliquer une modification ciblée, sans affecter les autres widgets Posts du site qui n’auraient pas le même identifiant.
Le hook elementor/query/{id}
Une fois le Query ID renseigné (par exemple biens-disponibles), Elementor Pro déclenche un hook dynamique nommé elementor/query/biens-disponibles juste avant l’exécution de la requête, avec l’objet WP_Query en cours de construction :
add_action( 'elementor/query/biens-disponibles', function( $query ) {
$query->set( 'meta_key', 'statut' );
$query->set( 'meta_value', 'disponible' );
$query->set( 'orderby', 'meta_value' );
$query->set( 'meta_type', 'CHAR' );
} );
Le hook s’exécute avant l’appel effectif à la base de données, ce qui permet d’ajouter n’importe quel paramètre WP_Query valide via set() : meta_query, tax_query, post__not_in, orderby personnalisé.
Exemple avec une meta_query complexe
add_action( 'elementor/query/biens-disponibles', function( $query ) {
$query->set( 'meta_query', [
'relation' => 'AND',
[
'key' => 'statut',
'value' => 'disponible',
'compare' => '=',
],
[
'key' => 'prix',
'value' => 500000,
'compare' => '<=',
'type' => 'NUMERIC',
],
] );
} );
Réutiliser le même Query ID sur plusieurs widgets
Rien n’empêche d’utiliser le même Query ID sur deux widgets Posts distincts, dans deux templates différents : le hook s’exécute de la même façon partout où ce Query ID est renseigné. C’est utile pour garantir la cohérence d’une règle métier (« toujours exclure les biens vendus ») sans avoir à écrire le filtre à plusieurs endroits.
| Approche | Portée | Complexité |
|---|---|---|
| Contrôles natifs du widget | Ce widget uniquement | Aucune, tout en interface |
| Query ID + hook PHP | Tout widget partageant le même ID | Quelques lignes PHP |
Filtre global pre_get_posts | Toute requête WordPress correspondante | Risque d’effets de bord sur d’autres requêtes |
Pourquoi préférer Query ID à pre_get_posts
Le hook générique pre_get_posts de WordPress s’applique à toutes les requêtes correspondant à ses conditions, y compris celles que vous n’aviez pas anticipées ailleurs sur le site. Le Query ID d’Elementor, lui, cible précisément un ou plusieurs widgets identifiés, ce qui rend le comportement prévisible et facile à documenter pour la suite du projet.
Nous documentons systématiquement chaque Query ID utilisé sur un projet dans un fichier de référence interne : identifiant, widget concerné, logique appliquée. Sans cela, un développeur qui reprend le projet plus tard ne devine jamais qu’un simple champ texte déclenche une modification de requête en base.
En résumé
Le champ Query ID transforme un simple identifiant texte en point d’ancrage pour une logique métier précise, via le hook elementor/query/{id}. C’est l’outil à privilégier dès que les contrôles natifs du widget Posts ne suffisent plus, avec un avantage net sur un filtre global pre_get_posts : la portée reste limitée aux widgets qui partagent explicitement cet identifiant, sans risque de casser une autre requête du site.
