Éditeur de site et Cloudflare APO : purger le cache après une template part

Le problème : Cloudflare Automatic Platform Optimization, l’extension officielle de mise en cache dédiée à WordPress, sait déjà purger automatiquement le cache d’une page lors de la publication ou de la modification d’un article classique. Elle ignore en revanche, en février 2022, les modifications apportées à un template part depuis le Site Editor, désormais disponible nativement depuis la sortie de WordPress 5.9 quelques semaines plus tôt.

Sur ce projet, une modification du pied de page, effectuée via un template part partagé sur l’ensemble des pages du site, restait invisible pendant plusieurs heures pour les visiteurs, tant que le cache Cloudflare APO n’expirait pas naturellement. Un changement pourtant enregistré, publié, mais qui n’apparaissait nulle part côté public.

Pourquoi APO ignore les template parts par défaut

Le mécanisme de purge automatique de Cloudflare APO s’appuie sur les hooks natifs de publication d’articles (save_post, transition_post_status), déclenchés normalement lors de la sauvegarde d’un contenu éditorial classique. Un template part, bien que techniquement stocké comme un article du type wp_template_part, n’est pas systématiquement traité par ces hooks de la même façon qu’un article ou une page classique, en particulier lorsqu’il est modifié directement dans l’interface du Site Editor plutôt que via l’écran d’édition classique.

Le snippet de purge ciblée

Plutôt que de purger l’intégralité du cache à chaque modification, ce qui annulerait temporairement tout le bénéfice de performance d’APO pour l’ensemble du site, la solution retenue déclenche une purge ciblée, limitée aux pages susceptibles d’utiliser le template part modifié.

add_action( 'save_post_wp_template_part', function ( $post_id, $post ) {
    if ( wp_is_post_revision( $post_id ) ) {
        return;
    }
    if ( function_exists( 'cloudflare_purge_by_url' ) ) {
        cloudflare_purge_by_url( home_url( '/*' ) );
    }
}, 10, 2 );

Cette première version, volontairement simple, purge l’ensemble des URL du site : un compromis assumé sur ce projet, faute d’un mécanisme fiable pour déterminer précisément quelles pages utilisent un template part donné, sans risquer d’oublier une page affectée par erreur.

Variante : purger uniquement via l’API Cloudflare directement

Sur les projets où le plugin officiel Cloudflare ne propose pas de fonction de purge programmatique exploitable, un appel direct à l’API REST Cloudflare, via wp_remote_post(), offre plus de contrôle et évite de dépendre d’une fonction interne susceptible de changer d’une version à l’autre du plugin.

wp_remote_post( 'https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache', array(
    'headers' => array(
        'Authorization' => 'Bearer ' . CLOUDFLARE_TOKEN_API,
        'Content-Type'  => 'application/json',
    ),
    'body' => wp_json_encode( array( 'purge_everything' => true ) ),
) );

Variante plus fine : purger uniquement les pages concernées

Une amélioration ultérieure, apportée après quelques semaines d’observation, consiste à maintenir une table de correspondance entre chaque template part et les pages qui l’utilisent réellement, construite en parcourant le contenu de chaque template au moment de sa modification, pour ne purger que les URL réellement concernées plutôt que l’ensemble du site.

• Déclencher la purge uniquement sur le hook spécifique save_post_wp_template_part, pas sur save_post générique.
• Exclure les révisions automatiques de l’enregistrement pour éviter des purges inutiles.
• Prévoir un délai d’attente côté équipe éditoriale avant de considérer une modification comme définitivement visible.

Une purge de cache mal ciblée coûte cher en performance perçue : mieux vaut accepter, temporairement, une purge un peu large plutôt qu’un cache qui reste périmé sans que personne ne comprenne pourquoi.

Ce que ce snippet ne couvre pas

Ce billet ne traite ni la configuration DNS de la zone Cloudflare, ni les réglages du pare-feu applicatif (WAF), deux sujets distincts qui dépassent le cadre de cette recette ciblée sur la seule purge liée aux template parts du Site Editor.

En résumé

Cloudflare APO reste un outil précieux pour la performance d’un site WordPress construit en éditeur de site, mais son support des template parts, encore jeune début 2022, nécessite un complément maison pour garantir une purge fiable. Un hook ciblé sur save_post_wp_template_part, avec une purge large en première approche, évite l’essentiel des décalages de contenu constatés sur ce projet.