Comment afficher des résultats de recherche pertinents dans un éditeur de site qui n’existe encore que sous forme de plugin expérimental ? C’est la question posée sur ce projet, pendant une phase de test du plugin Gutenberg en mode « Full Site Editing », où le bloc Query Loop commence tout juste à apparaître dans les patterns disponibles, aux côtés d’un bloc de recherche natif encore minimal.
Le bloc recherche natif de WordPress, à cette date, se contente d’une correspondance SQL classique sur le titre et le contenu des articles : aucune pertinence, aucune tolérance aux fautes de frappe, aucun tri par popularité. Sur un site de test contenant plusieurs centaines d’articles de démonstration, les résultats affichés paraissaient souvent hors sujet. L’idée a été de brancher Algolia, déjà utilisé sur d’autres projets de l’agence, directement sur ce bloc expérimental.
Pourquoi tester Algolia maintenant, avant la stabilisation du Site Editor
Le pari, ici, n’est pas de livrer une fonctionnalité en production : le Site Editor lui-même est encore expérimental, activé via le plugin Gutenberg, et son comportement change d’une mise à jour à l’autre. Mais comprendre comment un bloc expérimental de type Query Loop pourrait un jour recevoir des résultats externes, plutôt que de piocher directement dans la base MySQL locale, permet d’anticiper l’architecture des projets à venir.
Sur ce test, seul le bloc de recherche a été remplacé ; le bloc Query Loop qui affiche la liste d’articles reste, lui, alimenté par la requête WordPress classique le reste du temps. Le périmètre a été volontairement limité pour ne pas complexifier un thème déjà instable par nature.
Créer un bloc de recherche personnalisé côté client
Plutôt que de modifier le bloc recherche natif, encore trop lié au cœur de WordPress à ce stade, un bloc dynamique séparé a été enregistré, avec son propre rendu JavaScript côté éditeur et un script de requête côté front.
const algoliasearch = require('algoliasearch/lite');
const client = algoliasearch('APPID123', 'CLEPUBLIQUE456');
const index = client.initIndex('articles_demo');
document.querySelector('#wpm-algolia-search').addEventListener('input', async (e) => {
const { hits } = await index.search(e.target.value);
renderResults(hits);
});
La clé utilisée côté client est volontairement une clé de recherche publique, en lecture seule, générée depuis le tableau de bord Algolia : elle ne permet ni d’écrire, ni de modifier l’index, uniquement d’interroger les enregistrements déjà synchronisés.
Synchroniser le contenu vers l’index Algolia
Sans indexation, aucune recherche n’est possible. Un script PHP déclenché sur save_post pousse chaque article publié vers Algolia via son SDK PHP officiel :
- Récupérer le titre, l’extrait et l’URL de l’article au moment de l’enregistrement.
- Envoyer ces champs à l’index Algolia via
addObjects(), avec l’identifiant de l’article commeobjectID. - Supprimer l’enregistrement correspondant lorsqu’un article passe en corbeille.
Ce que ce test ne couvre pas
Ce premier essai reste volontairement restreint. Il ne traite pas l’indexation d’un catalogue WooCommerce, avec ses variations de produits et ses stocks changeants, ni la configuration complète d’Algolia (facettes, règles de tri personnalisées, tableaux de bord d’analytics). L’objectif était uniquement de vérifier la faisabilité technique d’un branchement externe sur un bloc du Site Editor encore expérimental.
Sur ce genre de test, il vaut mieux limiter le périmètre au strict nécessaire : un éditeur encore expérimental change de comportement d’une mise à jour à l’autre, et un périmètre large multiplie les points de rupture possibles.
Les limites rencontrées à ce stade
Le bloc personnalisé fonctionne correctement en façade, mais son intégration dans l’éditeur lui-même reste fragile : le panneau de réglages du bloc, censé permettre de configurer l’identifiant d’index directement depuis l’interface, provoque parfois une erreur silencieuse lors de l’enregistrement du template. Le contournement, pour l’instant, consiste à coder en dur l’identifiant d’index dans le fichier PHP du bloc, en attendant que l’API de blocs dynamiques du Site Editor se stabilise.
En résumé
Brancher Algolia sur un bloc de recherche dès la phase expérimentale du Site Editor est possible, à condition de garder un périmètre restreint : un seul bloc remplacé, une clé publique en lecture seule, une synchronisation simple sur la sauvegarde d’article. Ce test confirme surtout une intuition : l’architecture par blocs du futur éditeur de site facilitera, à terme, ce genre de branchement externe, bien plus qu’un thème classique construit autour de functions.php.
