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.