# wp_after_insert_post déclenche un rebuild sans plugin de webhook

> La documentation de WordPress décrit wp_after_insert_post comme le hook qui se déclenche une fois un article réellement enregistré en base, métadonnées comprises. Une base solide pour un rebuild propre.

- Auteur : WordPress Développement
- Publié le : 2021-09-23
- Mis à jour le : 2021-09-23
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/wp-after-insert-post-rebuild-sans-plugin-webhook/

## L’essentiel

- Le hook wp_after_insert_post attend que les métadonnées soient enregistrées
- Il évite les déclenchements prématurés propres à save_post
- Une seule fonction suffit pour notifier un service de build externe

La documentation de developer.wordpress.org décrit `wp_after_insert_post` comme le hook qui se déclenche une fois qu'un article est réellement enregistré en base de données, métadonnées comprises, contrairement à `save_post` qui peut se déclencher avant que certaines métadonnées associées n'aient fini d'être écrites.

Introduit dans WordPress 5.6 en décembre 2020, ce hook répond à un problème récurrent pour les projets headless qui déclenchent un rebuild statique à chaque publication : un déclenchement trop précoce du webhook de build risque de partir avant que des champs personnalisés essentiels, comme une image mise en avant ou une métadonnée ACF, n'aient été correctement enregistrés.

## Le problème que résolvait déjà save_post, imparfaitement

Avant l'arrivée de ce nouveau hook, `save_post` restait la solution la plus courante pour déclencher une notification externe. Son inconvénient tenait à son moment de déclenchement, parfois trop tôt dans le cycle d'enregistrement d'un article, notamment lorsque des métadonnées étaient ajoutées par un autre callback accroché au même hook mais exécuté après.

```
add_action( 'save_post', function( $post_id ) {
    // Risque : certaines métadonnées ne sont pas encore enregistrées ici
    wp_remote_post( 'https://build.exemple.fr/webhook', array(
        'body' => array( 'post_id' => $post_id ),
    ) );
} );
```

## Ce que change wp_after_insert_post

Ce hook garantit que l'ensemble du processus d'enregistrement, métadonnées incluses, est terminé au moment où la callback s'exécute. Il reçoit en argument l'objet complet de l'article, l'article précédent et un indicateur précisant s'il s'agit d'une mise à jour ou d'une création.

> L'essentiel à retenir : Le hook wp_after_insert_post attend que les métadonnées soient enregistrées ; Il évite les déclenchements prématurés propres à save_post ; Une seule fonction suffit pour notifier un service de build externe

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

    wp_remote_post( 'https://build.exemple.fr/webhook', array(
        'body'    => array( 'post_id' => $post_id, 'update' => $update ),
        'timeout' => 5,
    ) );
}, 10, 4 );
```

La vérification du statut `publish` évite de déclencher un rebuild pour un brouillon en cours de rédaction, ce qui aurait consommé des ressources de build sans aucun contenu réellement destiné à être publié.

## Distinguer création et mise à jour côté build

L'argument `$update`, booléen, permet d'adapter le message envoyé au service de build. Une création peut justifier une notification différente d'une simple mise à jour de contenu, par exemple pour déclencher une réindexation complète plutôt qu'un rebuild incrémental.

- Vérifier systématiquement le statut de publication avant tout appel externe
- Distinguer création et mise à jour via l'argument `$update`
- Fixer un `timeout` court sur l'appel sortant pour ne jamais bloquer l'enregistrement de l'article

> Un hook qui se déclenche au bon moment évite une classe entière de bugs qu'aucun correctif côté front ne pourra jamais compenser.

## Comparer avec un plugin de webhook du marché

Plusieurs extensions existent pour déclencher des notifications sortantes à la publication, avec une interface d'administration pour configurer les URLs cibles sans écrire de code. Elles restent pertinentes pour une équipe non technique qui doit gérer elle-même ses intégrations, mais ajoutent une dépendance supplémentaire à maintenir à jour, avec son propre cycle de mises à jour de sécurité.

Pour un projet où l'équipe technique reste disponible pour maintenir quelques lignes de code, la solution native via `wp_after_insert_post` évite cette dépendance, au prix d'une configuration figée dans le code plutôt qu'accessible depuis l'administration.

## Une limite à connaître avant de généraliser cette approche

Ce hook se déclenche pour tous les types de contenu, pas uniquement pour les articles standards. Sur un site avec de nombreux types de contenus personnalisés, un filtre sur `$post->post_type` reste indispensable pour éviter de déclencher un rebuild pour des contenus qui ne concernent pas le front headless, comme des enregistrements internes de journalisation.

## En résumé

Le hook `wp_after_insert_post`, disponible depuis WordPress 5.6, offre un point de déclenchement plus fiable que `save_post` pour notifier un service de build externe, sans dépendre d'un plugin tiers dédié aux webhooks. Cette recette ne couvre volontairement pas la gestion des files d'attente, utile dès que le volume de publications simultanées devient significatif.