# Query ID d’Elementor Pro : filtrer le widget Posts avec elementor/query

> Utiliser le hook elementor/query/{id} pour modifier finement la requête des widgets Posts et Portfolio d'Elementor Pro, au-delà de ce que propose l'éditeur.

- Auteur : Clément Hadrot
- Publié le : 2021-10-19
- Mis à jour le : 2021-10-19
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/query-id-elementor-pro-widget-posts/

## L’essentiel

- Le champ Query ID relie un widget à un hook PHP précis, sans toucher au reste du site
- Le hook reçoit directement l'objet WP_Query, modifiable via set()
- Deux widgets peuvent partager le même Query ID pour appliquer la même logique

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

> L'essentiel à retenir : Le champ Query ID relie un widget à un hook PHP précis, sans toucher au reste du site ; Le hook reçoit directement l'objet WP_Query, modifiable via set() ; Deux widgets peuvent partager le même Query ID pour appliquer la même logique

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