rest_after_insert_post valide un contenu juste avant sa sortie API

do_action( "rest_after_insert_{$post_type}", $post, $request, $creating ). Voilà la signature exacte, telle qu’on la trouve dans le cœur de WordPress, du hook qui s’exécute juste après qu’un contenu a été enregistré via l’API REST, mais avant que la réponse ne parte vers le client. C’est ce point d’exécution précis qui en fait un outil particulièrement utile dans une architecture headless, où le contenu est souvent créé ou modifié depuis un outil externe plutôt que depuis l’éditeur WordPress.

Contrairement à save_post, qui se déclenche pour toute sauvegarde quelle que soit son origine, rest_after_insert_{$post_type} ne concerne que les écritures passées par l’API REST. Cette spécificité permet d’appliquer des règles propres au flux headless sans interférer avec les sauvegardes faites directement depuis l’administration WordPress.

Ce que fait réellement le hook

Le nom du hook varie selon le type de contenu concerné : rest_after_insert_post pour les articles standards, rest_after_insert_page pour les pages, ou rest_after_insert_offre_emploi pour un type personnalisé nommé ainsi. Il reçoit trois arguments : l’objet WP_Post fraîchement enregistré, l’objet WP_REST_Request de la requête en cours, et un booléen $creating qui vaut true lors d’une création et false lors d’une mise à jour.

Un point important : ce hook s’exécute après l’insertion en base de données. Il ne permet donc pas de bloquer l’écriture elle-même — pour cela, il faut agir plus tôt, via rest_pre_insert_{$post_type}, qui reçoit les données avant leur insertion et peut retourner un objet WP_Error pour interrompre la requête. rest_after_insert_{$post_type} sert plutôt à réagir à une insertion déjà actée : corriger un champ, déclencher une notification, ou invalider un cache.

Cas d’usage : contrôler la cohérence d’une offre d’emploi diffusée en headless

Sur une plateforme de recrutement où les offres d’emploi sont créées par un outil RH externe via l’API REST puis affichées sur un front Nuxt, ce hook a permis de vérifier après chaque écriture que la date de clôture d’une offre n’était jamais antérieure à sa date de publication, une erreur de saisie qui arrivait régulièrement côté outil RH.

add_action( 'rest_after_insert_offre_emploi', function ( $post, $request, $creating ) {
    $date_publication = get_post_field( 'post_date', $post->ID );
    $date_cloture      = get_post_meta( $post->ID, 'date_cloture', true );

    if ( $date_cloture && strtotime( $date_cloture ) < strtotime( $date_publication ) ) {
        update_post_meta( $post->ID, 'date_cloture', '' );
        update_post_meta( $post->ID, '_offre_incoherente', true );
    }
}, 10, 3 );

Plutôt que de rejeter la requête, ce qui aurait cassé l’intégration côté outil RH sans préavis, le choix a été de vider le champ incohérent et de marquer discrètement le contenu pour une relecture manuelle. Une notification interne, envoyée via un second hook accroché au même événement, alertait l’équipe recrutement le jour même.

Distinguer création et mise à jour

Le paramètre $creating évite de dupliquer une notification à chaque modification mineure d’une offre déjà publiée :

• Si $creating vaut true, une notification Slack interne signale une nouvelle offre à relire
• Si $creating vaut false, seule une vérification silencieuse de cohérence est effectuée, sans notification
• Dans les deux cas, un cache de type transient lié à la liste des offres actives est invalidé, pour que le front reflète l’état à jour dès l’appel suivant

Un hook qui s’exécute après coup n’est pas un hook de validation au sens strict : c’est un hook de rattrapage. Les deux ont leur place, mais confondre les deux dans la documentation d’un projet finit toujours par créer un incident.

Ce que ce hook ne couvre pas

Les blocs dynamiques du contenu de l’offre — s’il en existait — ne sont pas concernés par ce mécanisme : rest_after_insert_{$post_type} travaille sur les champs et métadonnées du post, pas sur le rendu des blocs Gutenberg qui composeraient son corps. Un contenu créé par un outil externe via l’API REST contient généralement du texte brut ou du HTML simple, sans blocs à interpréter, ce qui sort de toute façon du cas d’usage traité ici.

En résumé

rest_after_insert_{$post_type} occupe une place précise dans le cycle de vie d’une requête REST : après l’écriture, avant la réponse. Ce positionnement en fait l’endroit naturel pour corriger, notifier ou invalider un cache sans bloquer un flux d’intégration externe, à condition de bien distinguer ce rôle de rattrapage de celui, plus strict, de rest_pre_insert_{$post_type} pour une véritable validation bloquante.