Proxy Cache Purge

FAQ

Veuillez signaler tous les problèmes sur forum de support

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

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

This plugin was originally adopted and updated for DreamHost’s DreamPress server, however it is not (and never has been) for DreamHost only.

I worked at DreamHost from 2012 to 2022, and have maintained the plugin since around 2014 or so.

As of October 2023, this plugin is NO LONGER installed by default on DreamPress.

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.

Caching is detected but cannot be confirmed. What does that mean?

It means that somewhere your server’s headers aren’t returning the data the plugin needs to see, in order to determine if the cache is working. The most common cause is that your server isn’t returning the X-Varnish header or the Age header.

I have renamed X-Varnish header for security reasons and Site Health Check says no cache service

You can use varnish_http_purge_x_varnish_header_name filter to customize this header name, like so:

function change_varnish_header( $default_header ) {
    return 'My-Custom-Header'; // Replace with the desired header
}
add_filter( 'varnish_http_purge_x_varnish_header_name', 'change_varnish_header' );