Subpages are not cached
If the $_GET
super global variable is customized for some reason, this might result in WP Rocket not caching and optimizing pages.
This can happen in some server environments, like NGINX (if customized), Plesk Onyx and IIS. The main symptom in these cases is seeing the homepage cached and optimized while internal pages are not.
It also can be caused by customizing the $_GET
on the wp-config.php
file. In this case, the issue can either be global or follow conditions used to personalize the $_GET
.
How to diagnose it?
You can output the content of the $_GET
variable by temporarily adding the following line on your theme's functions.php
file:
var_dump($_GET);
Some online resources suggest adding $_GET['classic-editor'] = true;
on the wp-config.php
file.
Checking any pages where the cache is not working would reveal the conflicting query string. In the above example:
array(1) { ["classic-editor"]=> bool(true) }
Why is this happening?
When query strings are present, WP Rocket does not cache those pages by default. This happens, for example, when you access: https://domain.com?nowprocket
Why is this happening in some server environments?
Let's take Plesk Onyx's as an example.
Their suggested configuration file, the one they recommend using with WordPress to enable permalinks, adds variables to the $_GET
array. The $_GET
array is the one the server creates when query strings like domain.com/?query=string are used in the URLs.
In this case, the cache works for the home page because the $_GET
array is empty, but when visiting an internal page, the page slug is added to the $_GET
array, disabling the cache.
With the query string being part of the request, WP Rocket will bypass cache and optimizations.
The same issue can take place for any NGINX and IIS server that is using a similar configuration.
How to fix it?
We suggest you tackle the root cause of the issue by applying the following fixes in the suggested order.
Fix for Plesk Onyx
The solution is to change the config file.
If you are using Plesk Onyx's suggested configuration for WordPress, you should see something like this:
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; }
Please change it as follows, and test again:
if (!-e $request_filename){ rewrite ^(.*)$ /index.php break; }
If you are not familiar with this kind of configuration, or in case you need assistance, please consult with Plesk support before implementing this.
Fix for IIS servers
In the web.config file, check if the permalinks rewrite rule looks similar to the following:
<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>
If so, please change it as follows:
<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 should be able to cache the subpages after making these changes.
Fix when the $_GET
variable is customized using PHP
The first thing to do is to confirm with the developers why the $_GET
had to be manipulated.
If no valid reason is found, remove the $_GET
declaration on the wp-config.php
file or the mu-plugin
will fix the issue.
Last resort if none of the above fixes is applicable
If the server configuration can't be changed, or the customized declaration for $_GET
needs to be preserved, you can add the additional query string(s) to our Cache Query String(s) feature.
The query string(s) to target will be based on the results of the var_dump($_GET);
. Based on the previous example where $_GET['classic-editor'] = true;
was used on the wp-config.php
file, adding classic-editor
to the Cache Query String(s) box will sort out the conflict.