wp elementor flush-css régénère bien les fichiers CSS générés par Elementor côté serveur, mais ne change rien tant que Cloudflare continue de servir une version mise en cache de la page HTML depuis son réseau de périphérie. Ce cas s’est présenté sur un site multi-pages fortement mis en cache, où une agence republiait régulièrement des templates de page d’atterrissage sans jamais voir le changement en ligne avant plusieurs heures.
La solution ne consiste pas à désactiver le cache Cloudflare (ce qui annulerait les gains de performance qui justifient sa présence), mais à déclencher une purge ciblée exactement au moment de la publication d’un template Elementor, via l’API Cloudflare.
Pourquoi une purge globale n’est pas la bonne réponse
L’API Cloudflare propose un point de terminaison de purge globale (purge_everything), séduisant par sa simplicité, mais à éviter en usage récurrent : il vide l’intégralité du cache du domaine, provoquant un pic de charge sur le serveur d’origine le temps que le cache se reconstruise, et consomme rapidement le quota d’appels API du plan Cloudflare en place (1 200 requêtes par mois sur les plans gratuits et Pro observés à l’époque).
Purge ciblée par URL, déclenchée à la publication
Elementor propose un hook natif, elementor/document/after_save, déclenché à chaque sauvegarde ou publication d’un document (page, template, popup) depuis l’éditeur. C’est le point d’ancrage idéal pour appeler l’API de purge ciblée de Cloudflare, limitée aux URL réellement concernées par la modification.
add_action( 'elementor/document/after_save', function( $document ) {
$url = get_permalink( $document->get_main_id() );
wp_remote_post(
"https://api.cloudflare.com/client/v4/zones/{$zone_id}/purge_cache",
[
'headers' => [
'Authorization' => 'Bearer ' . CLOUDFLARE_API_TOKEN,
'Content-Type' => 'application/json',
],
'body' => wp_json_encode( [ 'files' => [ $url ] ] ),
]
);
} );
Cas particulier des templates globaux
- Un template d’en-tête ou de pied de page modifié affecte potentiellement toutes les pages du site : la purge doit alors cibler une liste d’URL représentatives, pas une seule page
- Un template popup n’a pas d’URL propre : sa purge doit viser les pages sur lesquelles il est configuré pour s’afficher, récupérées via les conditions d’affichage Elementor Pro
- Le jeton API Cloudflare doit être limité en droits à la seule zone concernée et à la permission de purge, jamais un jeton global du compte
Vérifier que la purge a bien fonctionné
L’en-tête de réponse HTTP cf-cache-status, visible dans les outils de développement du navigateur, indique si une page provient du cache (HIT) ou du serveur d’origine (MISS ou DYNAMIC). Après une purge ciblée réussie, la première requête suivante sur l’URL concernée doit afficher MISS, preuve que Cloudflare est bien allé rechercher la version fraîche.
Conseil maison : loguer chaque appel de purge (URL ciblée, code de réponse Cloudflare) dans un fichier dédié permet de diagnostiquer rapidement un template qui semble « ne jamais se mettre à jour », souvent le signe d’une purge silencieusement échouée plutôt que d’un problème Elementor.
Limites de cette approche
Cette purge ciblée par hook ne couvre que les publications faites depuis l’éditeur Elementor. Une modification de contenu par un autre biais (import WP-CLI, modification directe en base) ne déclenche pas ce hook et nécessite une purge manuelle ou un déclencheur complémentaire, hors du périmètre traité ici. La configuration DNS et les règles de pare-feu applicatif (WAF) de Cloudflare ne sont pas non plus concernées par cet article.
En résumé
Brancher la purge Cloudflare sur le hook elementor/document/after_save permet de garder les bénéfices d’un cache agressif tout en donnant aux équipes éditoriales l’impression, justifiée, que leurs publications sont immédiatement visibles.
