# Éditeur de site et Algolia : brancher l’InstantSearch sur un template

> Adaptation du template search.html d'un thème bloc pour y insérer un widget Algolia InstantSearch, en remplacement de la recherche native.

- Auteur : WordPress Développement
- Publié le : 2023-09-26
- Mis à jour le : 2023-09-26
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/algolia-instantsearch-template-recherche/

## L’essentiel

- Template search.html conservé comme coquille d'accueil
- Widget InstantSearch monté sur une zone dédiée du template
- Recherche native désactivée uniquement sur cette page

`npm install algoliasearch instantsearch.js`. Cette seule commande a suffi à démarrer le remplacement de la recherche native d'un site e-commerce de niche, dont le catalogue de plusieurs milliers de références rendait la recherche WordPress par défaut trop lente et trop approximative pour les habitudes des visiteurs.

Ce billet décrit l'adaptation du template `search.html` d'un thème bloc pour y insérer un widget Algolia InstantSearch en JavaScript, à la place du résultat de recherche natif de WordPress. La configuration de l'index Algolia côté back-office et la facturation du service ne sont pas traitées ici, ce projet ayant déjà un index Algolia opérationnel en amont de ce chantier.

## Pourquoi garder le template plutôt que le contourner

Une approche fréquente consiste à rediriger complètement l'URL de recherche vers une page Algolia autonome, hors de l'écosystème WordPress. Cette solution a été écartée ici pour préserver la cohérence visuelle du site : en-tête, pied de page et navigation devaient rester identiques au reste du site, gérés par les template parts partagées du thème bloc.

Le template `search.html` a donc été conservé comme coquille d'accueil pour les template parts communes, mais son bloc `core/query` par défaut, qui affiche les résultats de la recherche native WordPress, a été remplacé par un unique bloc de groupe servant de point de montage pour le widget JavaScript Algolia.

## Adapter le template

Le fichier `templates/search.html` du thème bloc a été modifié pour insérer un bloc de groupe avec un identifiant HTML personnalisé, cible du montage JavaScript, à la place du bloc de requête natif.

> L'essentiel à retenir : Template search.html conservé comme coquille d'accueil ; Widget InstantSearch monté sur une zone dédiée du template ; Recherche native désactivée uniquement sur cette page

```
<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main","className":"wpm-algolia-search"} -->
<main class="wp-block-group wpm-algolia-search">
    <div id="wpm-algolia-searchbox"></div>
    <div id="wpm-algolia-hits"></div>
    <div id="wpm-algolia-pagination"></div>
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->
```

## Monter le widget InstantSearch

Le script est enfilé uniquement sur ce template, via une vérification de `is_search()` couplée à un contrôle du nom de template courant, pour éviter de charger la bibliothèque Algolia sur le reste du site.

```
function wpm_enqueue_algolia_search( $hook ) {
    if ( ! is_search() ) {
        return;
    }

    wp_enqueue_script(
        'wpm-algolia-search',
        get_theme_file_uri( '/assets/js/algolia-search.js' ),
        array(),
        wp_get_theme()->get( 'Version' ),
        true
    );

    wp_localize_script( 'wpm-algolia-search', 'wpmAlgolia', array(
        'appId'     => WPM_ALGOLIA_APP_ID,
        'searchKey' => WPM_ALGOLIA_SEARCH_KEY,
        'indexName' => 'produits_wpm',
    ) );
}
add_action( 'wp_enqueue_scripts', 'wpm_enqueue_algolia_search' );
```

Le fichier `algolia-search.js` initialise `instantsearch()` et y attache les widgets `searchBox`, `hits` et `pagination` sur les trois identifiants HTML définis dans le template. La requête initiale se déclenche dès le chargement, préremplie avec le terme de recherche transmis par WordPress via le paramètre `?s=`, pour que le comportement reste cohérent avec un lien de recherche partagé ou mis en favori.

## Désactiver la recherche native sur cette page uniquement

- Le hook `pre_get_posts` reste inutilisé ici : la requête WordPress native n'est jamais exécutée puisque le contenu affiché provient exclusivement du widget JavaScript côté client.
- Le titre de la page, lui, continue d'utiliser le bloc `core/query-title` natif, qui affiche correctement le terme recherché sans dépendre d'Algolia.
- Un message de secours, affiché par défaut dans le bloc de groupe avant le montage du script, garantit un contenu minimal si JavaScript est désactivé côté visiteur.

### Le gain mesuré

Sur ce catalogue, le temps de réponse moyen constaté côté widget Algolia se situe autour de 300 millisecondes, contre plus d'une seconde pour la recherche native WordPress sur les mêmes termes, cette dernière devant parcourir l'intégralité du contenu textuel des fiches produit sans index dédié à la recherche.

> Remplacer la recherche native ne signifie pas abandonner le template WordPress qui l'entoure : les deux peuvent coexister proprement.

## Notre verdict

Cette approche hybride, template WordPress classique et widget JavaScript autonome, offre un bon compromis entre cohérence visuelle et performance de recherche. Elle demande une vigilance particulière sur le chargement conditionnel du script, pour ne pas alourdir le reste du site avec une bibliothèque dont il n'a pas besoin.