Quelles pages/URL WordPress ne doivent jamais être mises en cache?
J'ai un blog multisite sur lequel un service de mise en cache Akamai sera installé, proposant du contenu mis en cache aux visiteurs (durée de vie de 15 minutes).
Je souhaite configurer Akamai de manière à exclure les URL importantes qui ne doivent jamais être mises en cache (c'est-à-dire, ne souhaitez pas servir les pages de connexion/d'administration mises en cache). Existe-t-il une compilation ou une recommandation générale de toutes les URL importantes qui ne doivent jamais être mises en cache? Voici ce que j'ai jusqu'à présent:
/wp-*(Cela empêcherait wp-includes/admins/etc)/xmlrpc.php- Toute URL avec avec
?preview=trueafin que les éditeurs puissent prévisualiser
Edit: Informations supplémentaires ci-dessous
Nous utilisons le cache Akamai Edge, qui est la mise en cache complète du site . Akamai agit en tant que serveur proxy inverse. Notre DNS est dirigé vers Akamai, les visiteurs se rendent directement à Akamai. Akamai ne nous envoie un message que pour mettre à jour les pages lorsque TTL expire ou lorsqu'une page demandée qui n'est pas déjà mise en cache est demandée.
Nous avons la possibilité d’exclure des parties du site de la mise en cache complète, par exemple des URL correspondant à wp-* ou des URL associées à la chaîne de requête preview=true. Les exclusions permettent le passage de cookies; POST demandes sont également autorisées.
Avec ces informations supplémentaires, il reste la question initiale: quels URL/chemins/etc spécifiques à WP doivent être exclus du mise en cache du site complet pour éviter que des incidents ne se produisent? Par exemple, les aperçus doivent évidemment être de nature dynamique, aussi l’ai-je exclu en autorisant la chaîne de requête preview=true. Quoi d'autre dois-je exclure? Est-ce que quelque chose correspondant à wp-* est suffisant, ou manque-t-il, à savoir /xmlrpc.php?
J'espère que les choses apportent un contexte supplémentaire à la question initiale.
Vous ne devriez rien mettre en cache dans l'admin pour que vos exemples soient corrects.
Un cache de proxy inverse nginx typique est configuré pour ignorer wp\-.*\.php|wp\-admin
Une autre option consiste à ne pas mettre en cache les utilisateurs connectés en vérifiant les cookies wp, mais vous n'avez probablement pas ce niveau de contrôle.
ps. Il est vivement conseillé de tester ceci avant d’inverser le commutateur.
tl; dr Vous devriez aller avec une installation de vanille.
Je ne crois pas qu'Akamai cache réellement la page entière. Toute ressource statique disponible publiquement convient pour la mise en cache et n'aurait aucune incidence sur les fonctionnalités du site, même si elles se trouvaient sur la page de connexion ou dans le tableau de bord.
Donc, vous n'avez pas besoin de bloquer.
La même chose ne peut pas être dite pour quelque chose comme W3 Total Cache, mais cela est résolu simplement en ne servant pas les fichiers en cache aux utilisateurs connectés ou en excluant des fichiers de thème ou de plug-in spécifiques.
Vous utilisez akamai en tant que serveur de mise en cache Web, vous aurez donc peut-être intérêt à rechercher des astuces pour utiliser squid, un outil de mise en cache Web populaire, avec wordpress.
Le problème avec la mise en cache est que vous ne voulez pas qu'un code HTML conçu pour un utilisateur spécifique soit mis en cache, et la manière appropriée de le faire lorsque vous travaillez avec des caches Web conformes est de définir l'en-tête http "Cache-Control" sur quelque chose comme "no-cache, must-revalidate, max-age = 0", qui correspond exactement à ce que wordpress envoie lorsqu'un utilisateur est connecté, de sorte que vous pourriez être OK sans effectuer de configuration.
Si vous avez la possibilité d’exclure par cookie, vous devriez peut-être ajouter une protection et une exclusion lorsque le cookie de connexion est défini (vous ne vous souvenez pas du nom exact) et il en va de même pour le cookie de commentateur si vous avez activé les commentaires afin que les commentateurs puissent pour voir leurs propres commentaires après les avoir soumis.
Si, après cela, vous avez toujours envie d'exclure des fichiers spécifiques, faites-le uniquement pour les fichiers php, car vous voulez que les fichiers js, css et les images sous/wp-inculde soient CDNed. Peut-être juste exclure tous les fichiers php sauf pour /index.php