A new option that would allow users to set parameters to be ignored, thus serving the cache when those are set (like we do automatically for utm, adsense or FB)
@jbma / @Tabrisrp Isn't this the same as Cache Query String(s) feature we have now?
We did in-depth analysis and discussion here https://github.com/websharks/comet-cache/issues/639
Nobody has solved it properly thus far.
@arunbasillal no it's different, the goal here is to serve the default cache file for defined GET parameters instead of creating a different specific one.
We currently do that for some of them directly in process.php, and this issue propose to add an option to add more to the default list
Customer requested as well: https://secure.helpscout.net/conversation/722636981/88975?folderId=1391600
The current implementation of "Cache Query String(s)" works great for GET parameters that are processed server side. A new cache entry is added for the specific request. E.g. you will get separate cache entries for page.php?category=shoes, page.php?category=jeans etc. This is great.
However, if you use GET parameters client site (Ajax or other js scripting), the current implementation does not work that well. E.g. for page.php?id=123123123, page.php?id=123123129 and page.php?id=88852 I want to serve the same cache entry and let Javascript do the processing of the GET parameters.
In the current implementation for every page.php?id=... a new cache entry is created which makes my cache folder huge. It also is not good for the visitor, since they don't get cached pages.
Since WP-Rocket already has this client side behavior for well known Javascript GET parameters (utm_campaing, gclid etc.), it would be relatively simple to add a setting for this.
$rocket_remove_query_strings in process.php - https://github.com/wp-media/wp-rocket/blob/de4009f5931f92362d9b841bfbb2c6b995fdf576/inc/front/process.php#L136(No new cache file is generated for each value of the query string present in $rocket_remove_query_strings)
Adding myself to this conversation as we have need with larger client sites that interact with InfusionSoft or other CRMs to remove more query strings from being uniquely cached.
Closing this in favor of #1597. Currently planned for 3.4.
Most helpful comment
Adding myself to this conversation as we have need with larger client sites that interact with InfusionSoft or other CRMs to remove more query strings from being uniquely cached.