# Un front headless republie une page supprimée : le cache oublié

> Une page supprimée depuis WordPress continue d'apparaître sur le front pendant plusieurs jours. Le diagnostic mène à une couche de cache jamais invalidée pour ce cas précis.

- Auteur : Clément Hadrot
- Publié le : 2024-06-21
- Mis à jour le : 2024-06-21
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/front-headless-republie-page-supprimee-cache/

## L’essentiel

- La suppression d'un contenu déclenche un hook différent de sa mise à jour
- Un cache invalidé uniquement sur la publication laisse passer les suppressions
- La solution consiste à couvrir tous les statuts de transition, pas seulement publish

« La fiche produit numéro 891 est censée avoir été retirée il y a quatre jours, pourquoi apparaît-elle encore sur le site ? » Le signalement, remonté par l'équipe commerciale, décrit un décalage simple à formuler mais révélateur d'un défaut de conception fréquent sur les architectures headless qui reposent sur une génération incrémentale de pages statiques.

Vérification faite côté WordPress : le contenu a bien été supprimé, la requête vers l'API REST correspondante retourne désormais une erreur 404 conforme. Le problème ne se situe donc pas côté source de vérité, mais quelque part entre cette source et ce que le visiteur voit réellement affiché.

## Le diagnostic : un webhook qui ne couvre qu'un seul événement

L'inspection du code qui déclenche la reconstruction des pages révèle la cause : le webhook de notification vers la plateforme d'hébergement du front n'est accroché qu'à l'action `publish_post`, un hook qui se déclenche à la publication ou à la mise à jour d'un contenu déjà publié, mais pas à sa suppression :

```
add_action( 'publish_post', function ( $post_id ) {
    wp_remote_post( 'https://front.exemple.test/api/revalider', array(
        'body' => array( 'chemin' => get_permalink( $post_id ) ),
    ) );
} );
```

Quand un contenu est supprimé, WordPress déclenche une action différente, `before_delete_post` ou `deleted_post` selon le moment précis souhaité dans le cycle de suppression, sans jamais passer par `publish_post`. Le webhook conçu uniquement autour de la publication ignore donc totalement l'événement de suppression, laissant la page statique déjà générée intacte, invisible à toute invalidation.

## Pourquoi ce cas passe facilement inaperçu en test

> L'essentiel à retenir : La suppression d'un contenu déclenche un hook différent de sa mise à jour ; Un cache invalidé uniquement sur la publication laisse passer les suppressions ; La solution consiste à couvrir tous les statuts de transition, pas seulement publish

Les scénarios de recette portent presque toujours sur la publication d'un nouveau contenu ou sa mise à jour, rarement sur sa suppression complète, jugée à tort comme un cas marginal. Ce biais de test explique pourquoi ce défaut peut survivre plusieurs mois en production avant qu'un contenu réellement supprimé ne révèle son existence.

## Le correctif : couvrir l'ensemble des transitions de statut

La solution la plus robuste consiste à s'accrocher au hook générique `transition_post_status`, qui se déclenche pour tout changement de statut, y compris vers `trash`, plutôt qu'à des actions spécifiques à un seul type de transition :

```
add_action( 'transition_post_status', function ( $nouveau, $ancien, $post ) {
    if ( $nouveau === $ancien ) {
        return;
    }

    $chemin = $nouveau === 'publish'
        ? get_permalink( $post )
        : home_url( '/produit/' . $post->post_name . '/' );

    wp_remote_post( 'https://front.exemple.test/api/revalider', array(
        'body' => array(
            'chemin' => $chemin,
            'action' => $nouveau === 'trash' ? 'supprimer' : 'mettre_a_jour',
        ),
    ) );
}, 10, 3 );
```

Côté front, la route `/api/revalider` doit interpréter le champ `action` pour distinguer une simple mise à jour, qui régénère la page, d'une suppression, qui doit au contraire retirer la page statique existante et faire répondre une erreur 404 pour toute requête ultérieure sur ce chemin.

## Vérifier que le correctif fonctionne réellement

- Supprimer un contenu de test et vérifier que le webhook correspondant est bien déclenché, pas seulement lors d'une publication.
- Vérifier côté front que la page statique associée disparaît effectivement du cache après réception de l'événement.
- Ajouter un contrôle périodique qui compare un échantillon de contenus supprimés côté WordPress avec leur état réel côté front, en complément du mécanisme événementiel.

> Un mécanisme d'invalidation pensé uniquement autour du cas le plus fréquent — la publication — laisse presque toujours filer le cas le plus rare mais le plus visible pour l'utilisateur final : la disparition d'un contenu qui reste, lui, obstinément affiché.

## En résumé

Ce type d'incident rappelle qu'un système d'invalidation de cache doit être pensé autour de l'ensemble des transitions possibles d'un contenu, pas seulement de sa mise en avant la plus visible. Remplacer un hook spécifique par un hook générique couvrant toutes les transitions de statut referme durablement ce type de trou, à condition de vérifier explicitement le comportement attendu côté front pour chaque cas.