Second preloaded page created when url has an utm parameter

If you have setup the permalink properly whether or not an URL has an UTM parameter WP will always add trailing shash to the end.

I mean https://example.com/sample/ instead of https://example.com/sample

Hi Saumya,

Yes, that may be true, but the code first removes unwanted trailing / and reintroduces a trailing / when there is an utm parameter, creating a different cache filename for the same path:

// Remove trailing /
if( substr($current_uri, -1, 1) == '/' )
  $current_uri = substr($current_uri, 0, -1);

$cache_key = str_replace( $replacements, '_', 
swcfpc_fallback_cache_remove_url_parameters($current_uri) ); // If utm parameter, replace query string with trailing /. 

// Create cache filename
$cache_key = sha1( $cache_key );

Hi,
Sorry I am confused here. So, before calling the swcfpc_fallback_cache_remove_url_parameters function with $current_uri it will always have a URL which does not have a trailing slash.

Then inside the swcfpc_fallback_cache_remove_url_parameters function it will always return the URL with the trailing slash. So, the URL getting logged in the system will always have trailing slash.

So, https://example.com/sample/?utm_campaign=test will become https://example.com/sample/.

So, $cache_key will be based of the URL with the trailing slash.

Am I missing something here?

Yes, but the $cache_key of https://example.com/sample/ will be based on https://example.com/sample without a trailing / as swcfpc_fallback_cache_remove_url_parameters only adds a trailing / when there is a utm parameter after removing the query string with the preg_replace.

swcfpc_fallback_cache_remove_url_parameters doesn’t do anything if there is no utm paramaterer. It just returns $current_uri without a trailing /, which was removed before the call swcfpc_fallback_cache_remove_url_parameters.

When https://example.com/sample/, $cache_key is based on https://example.com/sample.
When https://example.com/sample/?utm_campaign=test, $cache_key is based on https://example.com/sample/, which results in two different but identical cache files.

Holy smoke. I don’t know how I missed that. Yes, you are right. I don’t know how I missed that. Yes you are right. So, either we have to add the trailing slash in both cased or not add it when $action === true.

Yes, that would also work. But it suppose the simplest solution is not to add the / to result of reg_replace so $cache_key is always calculated without a trailing /.

By the way, a possibility to filter $current_uri just before $cache_key is calculated would be really nice. It would allow the theme to remove parameters that doesn’t affect the page output, like the utm parameters. The current method would then be the default filtering when there is no filter.

We use customers ids from our CRM system in our mail campaigns to identify that a mail recipient has visited our website. Without a filter we must add a dummy utm parameter so that the entire query string is removed, otherwise each visit to the same landing page will generate a new cache file. An innocent mail blast from the marketing department can thus result in thousands of identical cache files as each mail contains the same url but with a unique customer id parameter.

Hi @egelberg,

By the way, a possibility to filter $current_uri just before $cache_key is calculated would be really nice. It would allow the theme to remove parameters that doesn’t affect the page output, like the utm parameters. The current method would then be the default filtering when there is no filter.

– Just to clarify on this, you are saying currently the plugin is doing:
$cache_key = str_replace( $replacements, '_', swcfpc_fallback_cache_remove_url_parameters($current_uri) );

Where the $current_url is passed to the swcfpc_fallback_cache_remove_url_parameters() where bunch of predefined query parameters gets removed from the URL and then the cleaned up URL is returned.

But you are saying that instead you would like to have a filter where the system will pass on the $current_uri to the filter and you will perform all the query removal of yourself and then return the current URL. And that that case the system won’t pass the $current_uri to the swcfpc_fallback_cache_remove_url_parameters() anymore. Is that so?

So, basically in the plugin where you have:

$cache_key = str_replace( $replacements, '_', swcfpc_fallback_cache_remove_url_parameters($current_uri) );

It would be replaced with something like this:

if( has_filter( 'swcfpc_fc_modify_current_url' ) ) {
	
	// Modify the current URL by yourself to remove the query string or any other unwanted characters
	$current_uri = apply_filters( 'swcfpc_fc_modify_current_url', $current_uri );

	$cache_key = str_replace( $replacements, '_', $current_uri );

} else {

	$cache_key = str_replace( $replacements, '_', swcfpc_fallback_cache_remove_url_parameters($current_uri) );
}

Is that so? Looking forward to your reply.

100% correct! It would allow the theme to only keep parameters that are known to affect page output.

Furthermore, if you allow swcfpc_fallback_cache_get_current_page_cache_key to return false the filter could tell you when the theme doesn’t want the url to be cached by returning a falsy value. When there is a filter and to make it less confusing, I suppose it would be sensible to ignore the configuration settings that determine if a url should be cached. The filter can check the cookies as well, if needed.

In other words, when there is a filter, it takes on the responsibility of deciding which urls to cache and preload.

If well written, such a filter would make it much harder to overload the server deliberately or by mistake by repeatedly requesting a page with a varying query string. For many businesses, it is not an option to only cache ulrs that do not have a query string, as url parameters are used to assess the efficiency of email marketing campaigns.

I would be happy to test it out on our site https://phiab.com and in one of our email campaigns.

Furthermore, if you allow swcfpc_fallback_cache_get_current_page_cache_key to return false the filter could tell you when the theme doesn’t want the url to be cached by returning a falsy value. When there is a filter and to make it less confusing, I suppose it would be sensible to ignore the configuration settings that determine if a url should be cached. The filter can check the cookies as well, if needed.

– This will cause other issues inside the code. If you don’t want any URLs to be cached you can specify them in the plugin settings easily. The plugin already has a robust system of bypass caching.

You can download this build and test. Let me know.

Saumya,

I want test the build locally on my laptop first. How can I enable just the preloading and local caching without enabling Cloudflare caching?

One my laptop the plugin is configured identically to how our site is configure but with a nonsense api-key to keep my laptop from altering the live CF settings. Right now the plugin refuses to enable the local cache after updating the plugin as it receives an error from CF.

Can I put the plugin in some “ignore CF error” debug mode or do I need to patch the code somewhere.

I want test the build locally on my laptop first. How can I enable just the preloading and local caching without enabling Cloudflare caching?

– You can’t as the whole backbone of this plugin is Cloudflare. I would rather suggest you to test it on a subdomain. Provide the API key and then delete the page rule it created inside CF manually.