# Adapter search.html d’un thème bloc pour y brancher Algolia InstantSearch
> Un thème classique migré vers un thème bloc gardait sa recherche externe Algolia. Pas à pas pour insérer un widget InstantSearch dans le template search.html sans casser l'éditeur de site.
- Auteur : WordPress Développement
- Publié le : 2024-06-15
- Mis à jour le : 2024-06-15
- Catégorie : Thèmes
- URL : https://www.wpmoderne.fr/themes/algolia-theme-bloc-instantsearch-template-recherche/
## L’essentiel
- Le template search.html du thème bloc reste un fichier HTML statique côté rendu
- Le conteneur InstantSearch s'insère via un bloc HTML personnalisé compatible avec l'éditeur de site
- Le script d'initialisation reste géré côté wp_enqueue_script, inchangé par la migration
« Comment garder Algolia après la migration vers un thème bloc ? » — question posée après la bascule d'un site e-commerce d'un thème classique Underscores vers un thème bloc maison, la recherche externe Algolia InstantSearch étant en place depuis des années et hors de question à reconstruire depuis zéro.
Ce tutoriel détaille l'adaptation du template `search.html` pour y insérer un widget Algolia InstantSearch fonctionnel dans un thème bloc ; il ne traite ni la configuration de l'index Algolia côté back-office, ni les questions de facturation liées au volume de requêtes, qui relèvent d'un tout autre périmètre.
## Ce qui change et ce qui ne change pas avec un thème bloc
Dans un thème classique, le template `search.php` contenait directement le conteneur HTML du widget de recherche et le script d'initialisation, mêlés à la boucle WordPress classique le cas échéant contournée. Dans un thème bloc, le template `search.html` est un fichier de balisage de blocs, résolu par l'éditeur de site, mais qui produit en sortie un rendu HTML tout à fait similaire à ce que produirait un template PHP classique une fois passé par le rendu serveur.
La bonne nouvelle : le script Algolia InstantSearch lui-même, le CSS associé, et la logique de connexion à l'index n'ont pas besoin de changer d'une ligne. Seule la manière d'insérer le conteneur HTML cible dans le template diffère.
## Étape 1 : créer un bloc HTML personnalisé pour le conteneur
Plutôt que d'écrire du HTML brut dans `search.html` — ce qui fonctionnerait techniquement via le bloc natif « HTML personnalisé », mais resterait fragile aux futures modifications dans l'éditeur de site — la solution la plus robuste consiste à enregistrer un petit bloc dynamique dédié, dont le seul rôle est de produire le conteneur attendu par Algolia :
```
register_block_type( 'mon-theme/conteneur-recherche', [
'render_callback' => function() {
return ''
. ''
. '';
},
'category' => 'mon-theme',
'title' => __( 'Conteneur de recherche Algolia', 'mon-theme' ),
] );
```
Ce bloc, une fois enregistré, apparaît dans l'inserteur de blocs de l'éditeur de site, ce qui permet à une personne non technique de repositionner le conteneur de recherche dans le template `search.html` sans avoir à modifier du code, exactement comme n'importe quel autre bloc natif.
> L'essentiel à retenir : Le template search.html du thème bloc reste un fichier HTML statique côté rendu ; Le conteneur InstantSearch s'insère via un bloc HTML personnalisé compatible avec l'éditeur de site ; Le script d'initialisation reste géré côté wp_enqueue_script, inchangé par la migration
## Étape 2 : insérer le bloc dans le template search.html
Dans l'éditeur de site (Apparence > Éditeur), le template `Recherche` reçoit le nouveau bloc entre l'en-tête et le pied de page du template :
```
Résultats de recherche
```
Le résultat produit dans le rendu final est un HTML strictement équivalent à ce qu'un template classique aurait produit : les trois identifiants `algolia-searchbox`, `algolia-hits` et `algolia-pagination` sont présents et immédiatement disponibles pour le script InstantSearch.
## Étape 3 : le script d'initialisation, inchangé
Le script d'enregistrement et d'initialisation de la bibliothèque InstantSearch reste géré via `wp_enqueue_script()`, exactement comme avant la migration, ciblé sur le template de recherche :
```
add_action( 'wp_enqueue_scripts', function() {
if ( is_search() ) {
wp_enqueue_script(
'algoliasearch-lite',
'https://cdn.jsdelivr.net/npm/algoliasearch-lite@4/dist/algoliasearch-lite.umd.min.js',
[],
'4.20.0',
true
);
wp_enqueue_script(
'instantsearch',
'https://cdn.jsdelivr.net/npm/instantsearch.js@4/dist/instantsearch.production.min.js',
[ 'algoliasearch-lite' ],
'4.60.0',
true
);
wp_enqueue_script(
'mon-theme-init-recherche',
get_stylesheet_directory_uri() . '/assets/js/init-recherche.js',
[ 'instantsearch' ],
wp_get_theme()->get( 'Version' ),
true
);
}
} );
```
## Étape 4 : la feuille de style, à revérifier une seule fois
Le seul point de vigilance réel concerne les styles CSS du widget, qui ciblaient auparavant des sélecteurs enfants directs d'un conteneur généré par PHP. Le rendu du bloc HTML personnalisé du thème bloc peut introduire un niveau d'imbrication supplémentaire (le `` englobant), ce qui impose de vérifier que les sélecteurs CSS existants (`.ais-SearchBox`, `.ais-Hits`) ne dépendent pas d'un parent direct précis mais restent suffisamment génériques pour fonctionner malgré ce conteneur supplémentaire.
> Migrer vers un thème bloc ne change jamais le comportement d'un script JavaScript tiers ; cela change uniquement la façon dont son point d'ancrage HTML est généré dans la page.
## En résumé
Brancher Algolia InstantSearch sur un thème bloc ne demande ni de réécrire la logique de recherche, ni de renoncer à l'édition visuelle du template : un bloc dynamique minimal suffit à produire le conteneur HTML attendu, laissant le script et le style du widget strictement inchangés. Sur ce projet, l'adaptation complète — bloc, template, vérification CSS — a tenu en une demi-journée de travail, script d'initialisation compris.