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.

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
timeoutcourt 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.