# WP Rocket et pattern overrides : le cache qui sert une ancienne version

> Une modification de pattern override n'apparaît pas côté public : diagnostic du cache de page WP Rocket à purger après un override, sur un thème utilisant le plugin Gutenberg.

- Auteur : WordPress Développement
- Publié le : 2024-02-01
- Mis à jour le : 2024-02-01
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/wp-rocket-pattern-overrides-cache-perime/

## L’essentiel

- Symptôme : l'override reste invisible côté public malgré la sauvegarde
- Cause : le cache de page WP Rocket ignore la modification de contenu
- Correctif : hook de purge ciblé sur la sauvegarde du contenu associé

« Je viens de modifier le texte dans ce pattern, mais la page affiche toujours l'ancien texte » : ce signalement, reçu pendant la recette d'un site utilisant la fonctionnalité expérimentale de surcharge de pattern du plugin Gutenberg, a occupé une bonne partie d'une après-midi avant qu'on identifie la cause réelle, sans rapport avec le pattern lui-même.

Ce billet décrit le symptôme observé, le diagnostic du cache de page WP Rocket en cause, et le correctif de purge ciblée appliqué. Les autres réglages de WP Rocket et la configuration d'un CDN ne sont pas traités ici. Précision utile : au moment de ce projet, la fonctionnalité de surcharge de contenu par instance de pattern n'existait qu'en expérimental dans le plugin Gutenberg, pas encore stabilisée dans le cœur de WordPress.

## Symptôme : une modification invisible côté public

Le site utilisait un pattern d'encart promotionnel inséré sur une dizaine de pages produit, chacune avec un texte de réduction légèrement différent grâce à la surcharge de contenu activée sur ce pattern. Lors de la recette, une correction de texte effectuée sur une des pages n'apparaissait pas côté public, alors que l'aperçu dans l'éditeur affichait bien le nouveau texte.

Un rechargement forcé du navigateur, en vidant le cache local, ne changeait rien : le texte affiché restait l'ancien. Ce détail orientait d'emblée vers un cache serveur plutôt qu'un cache navigateur, puisque le contenu ne changeait pour aucun visiteur, y compris ceux qui n'avaient jamais consulté la page auparavant.

## Diagnostic : le cache de page ignore la sauvegarde

WP Rocket génère une page HTML statique lors de la première visite après chaque purge, avec une durée de vie par défaut de dix heures configurée sur ce site. Le mécanisme de purge automatique de WP Rocket se déclenche normalement à la sauvegarde d'un article ou d'une page, via les hooks natifs de publication de WordPress.

> L'essentiel à retenir : Symptôme : l'override reste invisible côté public malgré la sauvegarde ; Cause : le cache de page WP Rocket ignore la modification de contenu ; Correctif : hook de purge ciblé sur la sauvegarde du contenu associé

Le problème venait de la nature même de la surcharge de contenu de pattern : la modification n'était pas enregistrée comme une sauvegarde de la page elle-même, mais comme une donnée associée au bloc pattern inséré dans cette page, stockée dans les attributs du bloc au sein du contenu de la page. En théorie, cela aurait dû déclencher la purge au même titre qu'une modification classique ; en pratique, la modification passait par l'API REST de l'éditeur avec un statut d'enregistrement automatique qui n'invoquait pas systématiquement le hook `save_post` attendu par WP Rocket dans cette configuration précise.

```
wp rocket clean --confirm --url=https://exemple.fr/produit-demo/
```

Cette commande a immédiatement rafraîchi la page concernée, confirmant que le contenu en base était correct depuis le départ : seul le cache de page servait une version périmée.

## Correctif : une purge ciblée sur le contenu réel

La solution retenue a consisté à accrocher un hook supplémentaire sur l'action `rest_after_insert_page`, déclenchée par toute sauvegarde via l'API REST de l'éditeur, pour forcer une purge explicite de l'URL concernée, en complément du mécanisme natif de WP Rocket jugé insuffisamment fiable dans ce contexte précis.

```
add_action( 'rest_after_insert_page', function( $post ) {
    if ( function_exists( 'rocket_clean_post' ) ) {
        rocket_clean_post( $post->ID );
    }
} );
```

Cette fonction utilitaire, fournie par WP Rocket lui-même, purge spécifiquement le cache associé à un identifiant de post donné, sans nécessiter une purge globale du site à chaque modification.

## Ce qu'il faut retenir pour les fonctionnalités expérimentales

- Une fonctionnalité encore expérimentale dans le plugin Gutenberg peut interagir de façon imprévisible avec des mécanismes tiers construits autour des hooks stables du cœur de WordPress.
- Tester systématiquement le cycle complet modification-purge-affichage lors de la recette d'un site combinant plugin de cache et fonctionnalités expérimentales de l'éditeur.
- Documenter ce type de correctif temporaire pour le revoir une fois la fonctionnalité stabilisée dans une version future du cœur, son comportement interne pouvant évoluer d'ici là.

> Une fonctionnalité expérimentale mérite un test de bout en bout avec chaque outil déjà installé sur le site, pas seulement un test isolé dans l'éditeur.

## Notre verdict

Ce cas illustre un risque propre aux fonctionnalités expérimentales de l'éditeur de site : leur intégration avec l'écosystème existant d'un site, en particulier les plugins de cache, n'est pas toujours éprouvée au même niveau que les fonctionnalités stabilisées depuis plusieurs versions. Une purge explicite, ajoutée par prudence, a suffi ici à sécuriser le comportement en attendant que ce mécanisme mûrisse.