Proxy Cache Purge

Description

Cette extension n’installe pas ni ne configure un proxy de cache. Il sert d’interface avec ces services.

Une méthode courante de mise en cache du contenu des sites web consiste à utiliser la mise en cache par proxy inverse. Des exemples courants sont Varnish et Nginx. Ces systèmes permettent à un site Web de mettre à jour le contenu et de mettre en cache l’expérience du visiteur sans avoir besoin d’extensions complexes stockant les fichiers localement et utilisant l’espace disque d’un/une utilisateur/utilisatrice.

Un cache proxy inversé est installé devant un serveur et examine les requêtes. Si la page demandée est déjà mise en cache, elle fournit le contenu mis en cache. Sinon, elle génère la page et le cache à la demande.

L’extension Proxy Cache Purge envoie une demande de suppression (c’est-à-dire de vidage) des données mises en cache d’une page ou d’un article à chaque fois qu’il y a une modification.

Comment cela fonctionne

Lorsque le contenu d’un site est mis à jour par WordPress, l’extension contacte le service de cache proxy avec l’URL de la page, demandant la suppression du cache.

Toutes les pages ne sont pas supprimées du cache à chaque modification. Par exemple, lorsqu’un article, une page ou un type de publication personnalisé est modifié ou qu’un nouveau commentaire est ajouté, uniquement les pages suivantes seront purgées :

  • La page d’accueil
  • L’article/la page modifié/ée
  • Toutes les catégories, étiquettes et/ou taxonomies personnalisées associées à la page
  • Flux similaires
  • Pages API JSON associées

De plus, votre cache entier sera supprimé lors des actions suivantes :

  • Changement de thème
  • En appuyant sur le bouton Vider le cache dans la barre d’outils

Les extensions peuvent également s’accrocher aux actions de purge, pour filtrer leurs propres évènements afin de déclencher une purge.

Sur un réseau multisite utilisant des sous-dossiers, uniquement les administrateurs et administratrices de réseau peuvent purger le site principal.

Mode de développement

Si vous travaillez sur un site et devez désactiver la mise en cache de l’une des deux façons suivantes :

  1. Ajoutez define( 'VHP_DEVMODE', true ); à votre fichier wp-config.php
  2. Allez dans Proxy Cache -> Réglages et activez le mode de débogage pendant 24 heures à la fois

Cela brisera le cache lors du chargement de la page. Ce n’est pas recommandé pour la production !

WP CLI

Purge

Les commandes Purge vous permettent de vider le cache.

  • purger wp varnish – Vider le cache de votre page d’accueil
  • purger wp varnish [<url>] – Vider le cache pour une URL

Vous pouvez utiliser le paramètre --wildcard pour tout vider à partir de cette URL. Donc, si vous vouliez vider le cache pour tous les thèmes, vous feriez ceci :

  • purger wp varnish https://example.com/wp-content/themes --wildcard

Debug

Le débogage peut vous aider à comprendre pourquoi votre cache ne fonctionne pas aussi bien qu’il le pourrait. La valeur par défaut est pour votre page d’accueil, mais vous pouvez tester n’importe quelle URL sur votre domaine.

  • débogage de wp varnish [<url>]

Paramètres disponibles :

  • [--include-headers] — Inclure les en-têtes dans la sortie de vérification de débogage
  • [--include-grep] — Répertoires de thèmes et d’extensions actifs de Grep pour les problèmes courants

DevMode

Le mode développement vous permet de désactiver temporairement le cache.

  • wp varnish devmode [<activate|deactivate|toggle>] – Modifier l’état du mode de développement

Politique de confidentialité

Depuis la version 5, cette extension n’utilise plus aucune donnée distante.

Captures d’écran

  • Bouton de purge sur « Immédiatement » (administrateur du Tableau de bord)
  • Menu de la barre d’outils (avec le cache activé)
  • Menu de la barre d’outils (avec le cache désactivé)
  • Résultats du scanner
  • Modifier l’adresse IP du proxy
  • Activer le mode développement
  • Avertissement de mode de développement (préavis de 24 heures)

Installation

Aucune instruction spéciale ne s’applique.

Si vous disposez d’un service proxy tiers (tel que Sucuri ou Cloudflare), vous devrez ajouter une adresse IP sur le Cache proxy -> page Réglages. Vous pouvez également ajouter une définition à votre fichier wp-config.php : define('VHP_VARNISH_IP','123.45.67.89');

Lorsque vous utilisez des proxys basés sur Nginx, votre IP sera probablement localhost.

Prérequis

  • Jolis permaliens activé
  • Un service de cache proxy basé sur serveur (comme Varnish ou Nginx)

FAQ

Veuillez signaler tous les problèmes sur forum de support

Si vous avez des correctifs de code, les pull requests sont les bienvenues.

Cette extension met-elle en cache mes données ?

Non. Cette extension informe votre système de cache lorsque le contenu est mis à jour et supprime les données mises en cache à ce moment-là.

Pourquoi l’extension ne supprime-t-elle pas automatiquement tout le cache ?

Vitesse et stabilité. Vider trop de cache à chaque modification peut ralentir un serveur. Cette extension fait de son mieux pour déterminer ce qui doit être supprimé et quand, tout en fournissant des crochets que les développeurs/développeuses peuvent utiliser si nécessaire.

How many cached files are deleted when a post is updated?

It depends on the post, but in general the tool will delete cached content for:

  1. The post name
  2. The front page of the site
  3. All first pages of related tags/categories
  4. The JSON API pages
  5. All related RSS feeds

Is there a limit to how many pages I can purge at once?

Not really, but in order to prevent your site from crashing by running the same checks over and over, if you try to purge more than 50 URLs at once, the plugin will do a full purge. Normally this never happens, but there are some plugins that hook into the options to add more pages to purge on an update.

You can change this value in your settings, or via the define VHP_VARNISH_MAXPOSTS in your wp-config.php file.

Keep in mind, the count of 50 does not include category/tags, API, or RSS pages. It’s just the sheer number of individual posts/pages you’re trying to purge at once.

Puis-je supprimer la totalité du cache ?

Oui. Cliquez sur le bouton « Vider le cache » sur le Tableau de bord « Immédiatement » (voir la capture d’écran si vous ne le trouvez pas). Il y a aussi un bouton « Vider le cache » sur la barre d’outils d’administration.

Si vous ne voyez pas de bouton, votre compte ne dispose pas des autorisations appropriées. Seuls les administrateurs/administratrices peuvent vider l’intégralité du cache. Dans le cas d’un réseau multisite sous-dossier, seuls les administrateurs/administratrices réseau peuvent vider le cache du site principal.

L’extension supprimera-t-elle mon cache lorsque je modifierai des fichiers sur le serveur ?

Non. WordPress ne peut pas détecter ces changements de fichiers de sorte qu’il ne peut pas dire à votre cache quoi faire. Vous devrez utiliser les boutons Vider le cache lorsque vous aurez fini de modifier votre code.

Est-ce que toutes les extensions et thèmes WordPress fonctionnent avec un cache proxy ?

Non. Certains d’entre eux ont des comportements qui les empêchent de se mettre en cache, que ce soit par accident ou par conception. Il est incroyablement difficile de les déboguer, car la plupart des problèmes similaires sont contextuels (comme si vous enregistrez une page avec un paramètre spécial). J’ai fait de mon mieux pour signaler tous les problèmes possibles avec le débogueur.

Je suis développeur/développeuse, puis-je dire à votre cache de se vider dans mon extension/thème ?

Oui. Une documentation complète est disponible sur les filtres personnalisés dans le wiki.

Puis-je désactiver la mise en cache ?

Not permanently, and remember that this plugin is not actually caching your content.

You can use development mode to have WordPress attempt to tell your proxy service not to serve cached content, but the content will still be cached by the service.

Il y a trois façons de faire ceci :

  1. Choisissez « Mettre en pause le cache (24 heures) » dans le menu déroulant Cache de votre barre d’outils.
  2. Accédez aux réglages du cache proxy -> et activez le mode de développement
  3. Ajouter define( 'VHP_DEVMODE', true ); à votre fichier wp-config.php.

Les deux premières options permettront le mode de développement pendant 24 heures. Si vous travaillez sur le développement à long terme, vous devriez utiliser define.

Il n’est pas recommandé d’utiliser le mode développement sur les sites de production pendant de longues périodes, car cela ralentira votre site et perdra tous les avantages de la mise en cache en premier lieu.

Pourquoi le bouton de redémarrage du cache est-il manquant ?

Si vous avez désactivé la mise en cache via le define, vous ne pouvez pas redémarrer le cache via l’extension. Vous devrez changer define( 'VHP_DEVMODE', true ); en define( 'VHP_DEVMODE', false ); dans votre wp-config.php fichier.

L’extension supprimera-t-elle mon cache lorsque j’éditerai des fichiers sur le serveur ?

En raison des dommages que cela peut causer à un site, l’accès est limité aux administrateurs uniquement. Dans le cas d’un réseau multisite, seuls les administrateurs réseau peuvent désactiver la mise en cache et ils doivent le faire via wp-config.php pour des raisons de sécurité.

Pourquoi est-ce que je vois toujours du contenu mis en cache en mode développement ?

Tant que le mode développement est activé, votre serveur continuera à mettre en cache le contenu mais l’extension indiquera à WordPress de ne pas utiliser le contenu mis en cache. Cela signifie que les fichiers qui existent en dehors de WordPress (comme les CSS ou les images) peuvent servir du contenu mis en cache. L’extension fait de son mieux pour ajouter un paramètre No Cache à javascript et CSS, cependant si un thème ou une extension n’utilise pas les files d’attente WordPress appropriées, alors son contenu mis en cache sera affiché.

Pourquoi puis-je encore vider le cache en mode développement ?

Parce que le serveur continue à cacher toujours du contenu. L’extension fournit un moyen de vider le cache pour ces pages, ainsi que tout ce qui n’est pas inclus dans WordPress, pour votre commodité.

Comment puis-je savoir si tout est en cache ?

Depuis votre Tableau de bord WordPress, accédez à Cache proxy > Vérifiez la mise en cache. Là, une page analysera automatiquement votre page d’accueil et rapportera tous les problèmes trouvés. Cela inclut toutes les extensions problématiques connues. Vous pouvez l’utiliser pour analyser n’importe quelle URL de votre domaine.

Pourquoi rien n’est-il mis en cache lorsque j’utilise PageSpeed ?

PageSpeed aime mettre des en-têtes Caching pour dire de ne pas mettre en cache. Pour corriger ce problème, vous devez mettre ceci dans votre section .htaccess pour PageSpeed : ModPagespeedModifyCachingHeaders off

Si vous utilisez NGINX, c’est pagespeed ModifyCachingHeaders off;

Pourquoi mes modifications ne s’affichent-elles pas lorsque j’utilise CloudFlare ou un autre proxy ?

Lorsque vous utilisez CloudFlare ou tout autre service similaire, vous avez mis un proxy devant le proxy du serveur. En général, ce n’est pas une mauvaise chose, même si cela peut introduire une certaine latence du réseau (cela signifie que votre site peut fonctionner plus lentement car il doit traverser plusieurs couches pour accéder au contenu). Le problème survient lorsque WordPress essaie d’envoyer la demande de purge à votre nom de domaine et, avec un proxy, cela signifie le service proxy et non votre site web.

Sur un site unique, vous pouvez le modifier via le Cache proxy > Vérifiez la page mise en cache. Sur multisite, vous devrez ajouter ce qui suit à votre fichier wp-config.php : define('VHP_VARNISH_IP','123.45.67.89');

Remplacez 123.45.67.89 par l’adresse IP de votre serveur de cache proxy (pas CloudFlare). NE PAS mettre http dans cette définition. Si vous êtes sur nginx, vous voudrez utiliser localhost au lieu d’une adresse IP.

Si vous voulez utiliser WP-CLI, vous pouvez définir une option dans la base de données. Cela ne prévaudra pas sur la définition, et existe pour les personnes qui souhaitent utiliser les outils d’automatisation : wp option update vhp_varnish_ip 123.45.67.890

Pourquoi mes articles expirent/ne s’affichent-ils pas lorsque j’utilise CloudFlare ?

Ceci est généralement lié à la configuration APO de CloudFlare. J’ai un ticket ouvert avec CloudFlare essayant de déboguer cela, mais fondamentalement, tout ce qu’ils font avec APO « n’aime pas » la commande flush et expire (ou se bloque).

Pourquoi est-ce que j’obtiens une erreur 503 ou 504 à chaque mise à jour d’un article ?

Votre adresse IP est incorrecte. Vérifiez l’adresse IP de votre serveur, puis le réglage de l’adresse IP de votre cache proxy. S’ils ne sont pas identiques, c’est probablement pour cette raison.

Comment trouver la bonne adresse IP ?

Votre adresse IP proxy doit être l’une des adresses IP que le service écoute. Si vous utilisez plusieurs IP, ou si vous avez personnalisé vos ACL, vous devrez choisir ce qui n’entre pas en conflit avec vos autres réglages.

Par exemple, si votre cache proxy écoute sur une IP publique et privée, choisissez la privée. D’autre part, si vous avez demandé à Varnish d’écouter sur 0.0.0.0 (p. ex. « écouter sur toutes les interface possibles »), vous devrez vérifier quelle IP vous définissez commme votre ACL de purge pour autoriser (généralement 127.0.0.1 c’est à dire localhost), et l’utiliser (p. ex. 127.0.0.1 ou localhost).

Si votre hébergeur a configuré votre service, vérifiez sa documentation.

Que faire si j’ai plusieurs adresses IP de cache proxy ?

Vous pouvez les saisir, séparés par une virgule, sur la page des réglages.

Quelle version de Varnish est prise en charge ?

Jusqu’à présent, il a été signalé que cette extension fonctionne bien sur Varnish v 2 à v 6.5..

Est-ce que cela fonctionne avec la mise en cache Nginx ?

C’est possible, si vous avez configuré la mise en cache Nginx pour respecter la demande curl PURGE. Si cela ne fonctionne pas, essayez de définir votre IP Varnish sur localhost car Nginx nécessite un contrôle de service installé pour que l’adresse IP fonctionne.

Quelles devraient être mes règles de cache ?

C’est une question au-delà du support de l’extension. Je n’ai pas les ressources disponibles pour offrir une aide à la configuration. Voici quelques pièges de base à connaître :

  • Pour vider les données mises en cache, le service devra respecter la commande PURGE
  • Tous les services de cache ne configurent pas PURGE par défaut
  • Lors du vidage de l’ensemble du cache, l’extension envoie une commande PURGE de /.* et définit l’en-tête X-Purge-Method comme regex
  • Nginx s’attend à ce que l’adresse IP soit « localhost »

Comment puis-je voir ce que l’extension envoie au service de cache ?

Oui SI le service dispose d’une interface. Malheureusement, Nginx ne le fait pas. Des instructions détaillées peuvent être trouvées dans la section de débogage sur GitHub. Gardez à l’esprit que ces interfaces ont tendance à être uniquement en ligne de commande.

Vous ne travaillez pas chez DreamHost ? Est-ce officiel ou DreamHost uniquement ?

  • Oui, je travaille pour DreamHost
  • Non, cette extension n’est pas uniquement pour DreamHost

Cette extension est installée par défaut pour toutes les installations de DreamPress sur DreamHost, et je la maintiens pour DreamHost, mais ce n’était pas à l’origine une extension officielle de DreamHost, ce qui signifie que je continuerai à prendre en charge tous les utilisateurs/utilisatrices au mieux de mes capacités.

Avis

15 avril 2020
I host my site on a Dreampress host and I've been using this plugin for years with success and I was super comfy given the plugin is "Brought to you DreamHost." However a couple of weeks ago Dreamhost initiated a migration of my site to another server. Ever since then my site has been really slow when post updates have been performed (ie whenever wp_insert_post() is called). AJAX calls and routines would stall for ~30 seconds. After hours and hours debugging my code (custom plugin) it turns out this plugin caused the problem! When you specify a custom IP, and that IP no longer exists, the plugin stalls presumably because it's trying to connect to the old specified IP. Suggested improvements: 1) The plugin should detect this and spit out an error (to errors.log or ideally to admin console) if proxy connections are taking too long. I'm guessing it does a check when you first set an IP but perhaps it should do a more regular check. 2) Dreamhost operational processes should be modified given the plugin comes from Dreamhost! If Dreamhost choose to migrate someones site, they should check for the existence of this plugin, and either update the custom ip to suit the new host or perform some alternate remediation before migrating and breaking the site. I trust implementing both of these will go a long way to keeping a site operational and be well received by Dreamhost customers.
3 septembre 2016
Works as described, has awesome support, and is just generally rad. High fives to everyone involved.
Lire les 20 avis

Contributeurs & développeurs

« Proxy Cache Purge » est un logiciel libre. Les personnes suivantes ont contribué à cette extension.

Contributeurs

“Proxy Cache Purge” a été traduit dans 5 locales. Remerciez l’équipe de traduction pour ses contributions.

Traduisez « Proxy Cache Purge » dans votre langue.

Le développement vous intéresse ?

Parcourir le code, consulter le SVN dépôt, ou s’inscrire au journal de développement par RSS.

Journal

5.1.2

  • April 2022
  • Fix typo in readme

5.1.1

  • April 2022
  • Prevent two versions of the plugin from running at once.
  • Correct JSON

5.1

  • February 2022
  • WP 5.9 Compat
  • Rate limiting to prevent abuse – if you try to purge more than the max number of posts in a go (default 50), a purge ALL is triggered
  • Allows customizing the purge URL to support: (credit mickaelperrin)
  • Nginx cache purge mechanism that doesn’t support regex directives
  • Custom purge location