Un bloc modifié dans le mode Canvas de l’éditeur de site, enregistré, puis rechargé… et c’est l’ancienne version qui réapparaît à l’écran. Pas systématiquement : parfois le changement s’affiche immédiatement, parfois il faut attendre plusieurs minutes, parfois un rechargement forcé du navigateur suffit à le faire apparaître. Ce comportement erratique, observé en testant le plugin Gutenberg en mode expérimental derrière Cloudflare, a fait perdre une bonne partie d’une après-midi avant qu’un début d’explication n’émerge.
Le premier réflexe a été de suspecter l’éditeur lui-même : à ce stade de développement, le mode Canvas, qui affiche un aperçu du template directement dans l’interface d’édition, reste jeune et sujet à des comportements inattendus. Mais le décalage observé, précisément cinq minutes en moyenne avant que le changement n’apparaisse, correspondait de façon suspecte à une durée de cache classique.
Reproduire le problème avant d’accuser l’éditeur
Avant de remonter un ticket sur le suivi du plugin Gutenberg, la méthode la plus sûre consiste à reproduire le comportement en isolant les variables : désactiver temporairement Cloudflare (en passant le domaine en DNS only, ou via un sous-domaine de test non proxifié) et vérifier si le décalage persiste. Sur ce projet, une fois Cloudflare désactivé, chaque modification apparaissait immédiatement dans le mode Canvas, sans aucun délai.
Ce test simple a suffi à écarter l’éditeur de la liste des suspects : le problème venait bien d’une couche de cache placée devant le site, et non d’un défaut du plugin en cours de développement.
Comprendre pourquoi le cache de page perturbe le Canvas
Le mode Canvas de l’éditeur de site fonctionne en interrogeant, en arrière-plan, les mêmes points d’entrée que ceux utilisés pour afficher le site public : c’est précisément ce qui permet un aperçu fidèle. Mais cela signifie aussi que ces requêtes passent par les mêmes règles de cache que le trafic public, y compris lorsqu’elles sont émises depuis l’écran d’administration d’un utilisateur connecté.
Cloudflare, configuré avec des règles de cache par défaut, ne fait pas systématiquement la différence entre une requête de visiteur anonyme et une requête émise par l’éditeur pour générer son aperçu, si l’URL interrogée ressemble à une URL publique classique. Le contenu mis en cache lors d’une requête antérieure est alors resservi tel quel, sans tenir compte du changement récemment enregistré.
Identifier précisément les requêtes concernées
L’outil de développement du navigateur, onglet réseau, permet de repérer les requêtes en cause : chaque appel effectué par le mode Canvas apparaît avec son statut de cache dans les en-têtes de réponse, notamment cf-cache-status. Une valeur HIT confirme que Cloudflare a servi une réponse mise en cache plutôt que d’interroger le serveur d’origine.
- Ouvrir l’onglet réseau des outils de développement pendant une session dans le mode Canvas.
- Filtrer les requêtes vers les points d’entrée utilisés par l’aperçu.
- Vérifier la valeur de l’en-tête
cf-cache-statussur chacune.
Exclure proprement les routes concernées
La correction retenue consiste à créer une règle de contournement de cache (« Cache Bypass ») dans le tableau de bord Cloudflare, ciblant spécifiquement les chemins liés à l’administration et à l’éditeur, plutôt que de désactiver le cache pour l’ensemble du site, ce qui annulerait tout le bénéfice de performance pour les visiteurs réels.
Règle Cloudflare :
SI URI contient "/wp-admin/"
OU cookie contient "wordpress_logged_in_"
ALORS Cache Level = Bypass
La condition sur le cookie de connexion WordPress est essentielle : sans elle, un visiteur non connecté qui consulterait par erreur une URL d’administration continuerait de recevoir du contenu potentiellement périmé pour ces pages, alors que l’objectif est justement de ne jamais mettre en cache une session administrateur active.
Ce que cette configuration ne couvre pas
Cette règle résout le décalage observé dans l’éditeur, mais ne constitue pas une configuration Cloudflare complète : la mise en cache du contenu public, les règles de pare-feu applicatif, ou l’optimisation des règles de page (Page Rules) restent des sujets à part entière, non traités ici. De la même façon, ce billet ne présage en rien des futures fonctionnalités du FSE une fois stabilisées, qui pourraient gérer ce type de conflit différemment.
Sur ce genre de diagnostic, la question à se poser en premier n’est jamais « qu’est-ce qui a changé dans WordPress », mais « qu’est-ce qui se trouve entre le navigateur et WordPress » : neuf fois sur dix, la réponse se trouve dans cette couche intermédiaire.
En résumé
Un décalage de contenu dans le mode Canvas de l’éditeur de site expérimental ressemble beaucoup à un bug de l’éditeur, mais provient très souvent d’un cache de page mal configuré, qui traite les requêtes d’aperçu comme du trafic public ordinaire. Isoler le problème en désactivant temporairement le cache, puis exclure précisément les routes d’administration plutôt que tout le cache, permet de retrouver un aperçu fiable sans sacrifier la performance du site public.
