elementor/query/query_id_personnalise : ce filtre PHP est le point d’entrée qui permet de faire dialoguer un widget Loop Grid Elementor Pro avec un moteur de recherche externe comme Algolia, sans reconstruire l’affichage des résultats à la main. Le principe général reste inchangé par rapport à un Loop Grid classique : seule la source des identifiants de contenus affichés change.
Le besoin sur ce projet était précis : un widget Loop Grid affiche un catalogue de fiches produits ou d’articles, et la recherche doit se faire côté client, en temps réel, sans rechargement de page complet, avec un moteur qui gère la pertinence bien mieux qu’une requête SQL classique sur du texte libre.
Rappel du fonctionnement du Query ID
Chaque widget Loop Grid Elementor Pro peut recevoir un identifiant de requête personnalisé dans son panneau de réglages, sous l’onglet Requête. Cet identifiant sert ensuite de point d’accroche pour un filtre PHP qui reçoit les arguments de la requête WordPress avant exécution, et peut les modifier ou les remplacer entièrement.
add_action('elementor/query/produits_recherche', function ($query) {
$ids = get_transient('algolia_resultats_' . session_id());
if (!empty($ids)) {
$query->set('post__in', $ids);
$query->set('orderby', 'post__in');
}
});
Étape 1 : capturer la saisie côté client
Un champ de recherche, ajouté en widget HTML personnalisé au-dessus du Loop Grid, écoute la saisie avec un léger anti-rebond (300 millisecondes) avant d’interroger l’API Algolia directement depuis le navigateur, via la clé API de recherche publique (jamais la clé d’administration).
Étape 2 : transformer les résultats Algolia en identifiants WordPress
Chaque objet indexé dans Algolia porte l’identifiant du contenu WordPress correspondant en attribut personnalisé (post_id), synchronisé à chaque publication via le hook save_post. La réponse Algolia, reçue côté client, est donc directement exploitable pour reconstituer une liste ordonnée d’identifiants WordPress.
const results = await index.search(query);
const ids = results.hits.map(hit => hit.post_id);
await fetch('/wp-json/recherche/v1/set-ids', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ ids })
});
document.dispatchEvent(new CustomEvent('elementor/popup/show'));
elementorFrontend.elements.$window.trigger('elementor/loop-grid/reload');
Étape 3 : stocker temporairement et recharger le Loop Grid
Un point d’API REST maison stocke la liste d’identifiants reçue dans un transient lié à la session, que le filtre PHP présenté plus haut vient ensuite lire au moment où Elementor reconstruit la requête du Loop Grid. Le widget se recharge alors en AJAX natif, sans rechargement complet de la page, en utilisant le mécanisme de pagination déjà intégré à Elementor Pro.
Ordre des résultats préservé
Le point le plus facile à manquer : sans l’instruction orderby => post__in, WordPress réordonne les résultats selon sa logique par défaut et perd tout l’intérêt du classement par pertinence calculé par Algolia. Cette ligne garantit que l’ordre de pertinence Algolia est respecté jusqu’à l’affichage final.
Limites constatées
- La pagination Elementor native reste liée au nombre total d’identifiants transmis, pas à une pagination Algolia côté serveur
- Un délai de propagation existe entre une publication WordPress et sa disponibilité dans l’index Algolia
- La recherche à facettes (filtres croisés) demande un widget de filtres personnalisé en plus du champ de recherche simple
Cet article ne couvre ni la configuration de l’index Algolia lui-même (structuration des attributs, règles de pertinence), ni les questions de facturation liées au volume de requêtes, deux sujets à traiter séparément selon l’usage réel du site.
Le Query ID d’un Loop Grid n’est qu’une porte d’entrée : ce qui compte, c’est ce qu’on décide d’y faire passer avant qu’Elementor ne construise sa requête.
En résumé
Brancher Algolia sur un Loop Grid Elementor Pro ne demande ni fork du plugin ni widget personnalisé complexe : un filtre PHP sur le Query ID, une capture de recherche côté client, et un point d’API pour transmettre les identifiants suffisent à obtenir une recherche instantanée à 180 millisecondes de temps de réponse moyen, sans sacrifier l’ergonomie d’édition native du Loop Grid.
