Les sous-pages ne sont pas mises en cache
Si la super variable globale $_GET est customisée pour une raison quelconque, il se peut que WP Rocket ne mette pas en cache et n'optimise pas les pages.
Dans certains environnements NGINX, Plesk Onyx et IIS, vous pouvez remarquer que la page d'accueil de votre site Web est mise en cache par WP Rocket, mais pas les pages internes. Cela peut être lié à la configuration de votre serveur.
Pourquoi cela se produit-il ?
Si vous utilisez le fichier de configuration suggéré par Plesk Onyx, celui qu'ils recommandent d'utiliser avec WordPress afin d'activer les permaliens, leur configuration ajoute également des variables à l'array $_GET. L'array GET est celui que le serveur crée lorsque des chaînes de requête comme domain.com/?query=string sont utilisées dans les URL.
Le même problème peut se poser pour tout serveur NGINX et IIS utilisant une configuration similaire.
Lorsque des chaînes de requête sont présentes, WP Rocket ne met pas ces pages en cache par défaut. Cela se produit, par exemple, lorsque vous accédez à https://domain.com?nowprocket
Dans ce cas, le cache fonctionne pour la page d'accueil car l'array $_GET est vide, mais lorsqu'on visite une page interne, le slug de la page est ajouté à l'array $_GET, ce qui désactive le cache.
Comment le diagnostiquer ?
Vous pouvez afficher le contenu de la variable $_GET en ajoutant temporairement la ligne suivante dans le fichier functions.php de votre thème :
var_dump($_GET);
Certaines publications en ligne suggèrent d'ajouter $_GET['classic-editor'] = true; au fichier wp-config.php.
La vérification de toutes les pages où le cache ne fonctionne pas révélerait la chaîne de requête conflictuelle. Dans l'exemple ci-dessus :
array(1) {
["classic-editor"]=>
bool(true)
}
Correctif pour Plesk Onyx
La solution consiste à modifier le fichier de configuration.
Si vous utilisez la configuration suggérée par Plesk Onyx pour WordPress, vous devriez voir quelque chose comme ceci :
if (!-e $request_filename) {
set $test P;
}
if ($uri !~ ^/(plesk-stat|webstat|webstat-ssl|ftpstat|anon_ftpstat|awstats-icon|internal-nginx-static-location)) {
set $test "${test}C";
}
if ($test = PC) {
rewrite ^/(.*)$ /index.php?$1;
}
Veuillez le modifier comme suit, et testez-le à nouveau :
if (!-e $request_filename){
rewrite ^(.*)$ /index.php break;
}
Si vous n'êtes pas familier avec ce type de configuration, ou si vous avez besoin d'aide, veuillez consulter l'assistance Plesk avant de la mettre en place.
Correctif pour les serveurs IIS
Dans le fichier web.config, vérifiez si la règle de réécriture des permaliens ressemble à ce qui suit :
<rule name="WordPress Permalink Rule" enabled="true" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="index.php?page_id={R:0}" />
</rule>
Si c'est le cas, veuillez le modifier comme suit :
<rule name="Main Rule" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="index.php" />
</rule>
WP Rocket devrait être capable de mettre en cache les sous-pages après avoir effectué ces modifications.
Correctif quand la variable $_GET est modifiée à l'aide de PHP
La première chose à faire est de confirmer avec les développeurs la raison pour laquelle la $_GET a dû être modifiée.
Si aucune raison valable n'est trouvée, supprimer la declaration $_GET depuis le fichier wp-config.php ou avec un mu-plugin résoudra le problème.
Dernier recours si aucune des solutions ci-dessus n'est applicable
Si la configuration du serveur ne peut pas être modifiée, ou si la déclaration personnalisée de $_GET doit être préservé, vous pouvez ajouter la ou les chaînes de requête supplémentaires à notre option Cacher les Query String(s).
La ou les chaînes de requête à cibler seront basées sur les résultats de var_dump($_GET);. Sur la base de l'exemple précédent où $_GET['classic-editor'] = true; a été utilisé dans le fichier wp-config.php, ajouter classic-editor à Cacher les Query String(s) réglera le conflit.