# Compatibilité Algolia et widget Posts Elementor : indexation en temps réel

> Mettre en place une synchronisation en temps réel entre Algolia et les articles affichés par le widget Posts d'Elementor, sans dépendre d'une tâche planifiée.

- Auteur : Clément Hadrot
- Publié le : 2024-12-24
- Mis à jour le : 2024-12-24
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/algolia-widget-posts-elementor-indexation-temps-reel/

## L’essentiel

- Le widget Posts n'a aucune conscience d'Algolia par défaut
- Les hooks save_post et before_delete_post déclenchent la synchronisation
- Une file d'attente évite de saturer l'API lors des imports massifs

« Pourquoi mon nouvel article n'apparaît pas dans les résultats de recherche alors qu'il est publié depuis dix minutes ? » Cette question revient régulièrement dès qu'un site combine Algolia pour la recherche et le widget Posts d'Elementor pour l'affichage du contenu. La réponse tient en une phrase : ce sont deux systèmes totalement indépendants, et rien ne les relie tant qu'on ne l'a pas codé soi-même.

Le widget Posts d'Elementor interroge directement la base de données WordPress via `WP_Query`, sans jamais consulter Algolia. De son côté, Algolia ne sait rien de ce qui se passe dans WordPress tant qu'aucun événement ne lui pousse les données à indexer. Ce billet détaille comment brancher ces deux mondes pour obtenir une indexation en temps réel, sans toucher à la configuration de l'index Algolia ni à la question de la facturation, qui dépendent du plan choisi et sortent du périmètre technique traité ici.

## Le principe : synchroniser sur les hooks WordPress, pas sur un cron

La première tentation consiste à planifier une tâche cron qui réindexe tout le contenu toutes les heures. Cette approche fonctionne, mais elle introduit un délai qui peut atteindre soixante minutes entre la publication d'un article et sa disponibilité dans les résultats de recherche affichés ailleurs sur le site. Pour un site d'actualité ou un blog à publication fréquente, ce délai est inacceptable.

La bonne pratique consiste à synchroniser Algolia directement sur les hooks natifs de WordPress qui encadrent le cycle de vie d'un article : `save_post` pour la création et la modification, `before_delete_post` pour la suppression, et `transition_post_status` pour gérer les cas de dépublication ou de passage en brouillon.

## Mise en place de la synchronisation

> L'essentiel à retenir : Le widget Posts n'a aucune conscience d'Algolia par défaut ; Les hooks save_post et before_delete_post déclenchent la synchronisation ; Une file d'attente évite de saturer l'API lors des imports massifs

Le code suivant illustre une synchronisation minimale mais fonctionnelle, à adapter selon le type de contenu affiché par le widget Posts (ici, le type `post` standard) :

```
add_action( 'save_post_post', function( $post_id, $post, $update ) {
    if ( wp_is_post_revision( $post_id ) || $post->post_status !== 'publish' ) {
        return;
    }

    $client = \Algolia\AlgoliaSearch\SearchClient::create(
        'APP_ID',
        'ADMIN_API_KEY'
    );
    $index = $client->initIndex( 'articles_wpmoderne' );

    $index->saveObject( [
        'objectID' => $post_id,
        'title'    => get_the_title( $post_id ),
        'excerpt'  => get_the_excerpt( $post_id ),
        'url'      => get_permalink( $post_id ),
        'date'     => get_post_time( 'U', false, $post_id ),
    ] );
}, 10, 3 );

add_action( 'before_delete_post', function( $post_id ) {
    $client = \Algolia\AlgoliaSearch\SearchClient::create( 'APP_ID', 'ADMIN_API_KEY' );
    $client->initIndex( 'articles_wpmoderne' )->deleteObject( $post_id );
} );
```

Ce déclenchement immédiat, dès l'appel de `save_post_post`, garantit une latence de l'ordre de quelques centaines de millisecondes entre l'enregistrement de l'article dans WordPress et sa présence dans l'index Algolia, ce qui correspond au temps de traitement de l'appel API lui-même.

## Gérer le cas des imports massifs

Le point de rupture de cette approche apparaît lors d'un import massif de contenu, par exemple une migration depuis un ancien site avec plusieurs milliers d'articles importés d'un coup via WP-CLI ou un plugin d'import. Déclencher un appel API Algolia synchrone pour chaque article revient à multiplier les requêtes HTTP et peut ralentir considérablement l'import, voire provoquer des erreurs de limitation de débit côté Algolia.

La solution consiste à mettre en file d'attente les objets à synchroniser plutôt que de les envoyer un par un, en s'appuyant sur l'API Batch d'Algolia :

```
wp cli cmd wp algolia:reindex --batch-size=100
```

Concrètement, une commande WP-CLI personnalisée peut collecter les identifiants des articles concernés, les regrouper par lots de cent, et appeler `$index->saveObjects()` pour chaque lot plutôt qu'un appel individuel par article. Cette méthode réduit le nombre de requêtes HTTP d'un facteur cent et évite les limitations de débit.

## Faire coexister le widget Posts et les résultats Algolia

Un point de confusion fréquent : le widget Posts d'Elementor continue d'afficher le contenu directement depuis la base WordPress, indépendamment d'Algolia. La synchronisation décrite ici sert uniquement à alimenter un index de recherche externe, utilisé par exemple par un widget de recherche personnalisé ou une barre de recherche InstantSearch ajoutée en complément. Le widget Posts, lui, n'a besoin d'aucune modification : il continue de fonctionner avec `WP_Query` comme d'habitude.

- Le widget Posts affiche le contenu : source de vérité = base de données WordPress
- Algolia sert la recherche : source de vérité = index synchronisé par les hooks
- Les deux doivent rester alignés, mais ne partagent aucune logique de rendu commune

## En résumé

Synchroniser Algolia avec le contenu affiché par le widget Posts d'Elementor ne demande pas de modifier le widget lui-même, mais de brancher des hooks WordPress standards sur le cycle de vie des articles. Pour un usage courant, la synchronisation événementielle via `save_post_post` et `before_delete_post` suffit largement. Pour les imports massifs, il faut basculer sur un traitement par lots via l'API Batch, sous peine de saturer les quotas de requêtes de l'API Algolia.