Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Super Page Cache for Cloudflare — Guide for using Remove Cache Buster Query Parameter feature (when using Cache Everything page rule)

Implementation Guide for using "Remove Cache Buster Query Parameter" feature

The Super Page Cache for Cloudflare plugin has recently added the feature for using the Cache Everything pagerule withing the ?swcfpc=1 cache buster query paramater. This opens up so many new doors where users previously had to use the Cloudflare Workers to remove the cache buster.

With this new option now users are able to take advantage of Cloudflare Cache Everything page rule and take it to the next level by using the new Rulesets released by Cloudflare. Basically this is achived by taking advantage of the all new Cache Rules feature implemented by Cloudflare.


Setp 1 — Setting up the Cache Rules inside your Cloudflare Dashboard

The first thing that you need to do is, log-in to your Cloudflare Dahsbord and go to the domain/zone doe which you are setting up the Super Page Cache for Cloudflare plugin. Then from the left hand side menus, go to Caching > Cache Rules.

Cache Rules Section

Then inside the Cache Rules page, click on the Create Cache Rule button. Then finally on the Create new Cache Rule page, click on the Edit Expression link.

Edit Expression Link

Now it's time to create all the Cache Rules we need... So, let's get started...

Super Important Note Badge
Make sure you replace example.com with your actual website hostname e.g. something.com or www.something.com etc. in the code given below before copy/pasting it.

Rule 1 ➜ Cache Bypass — WP Admin Paths, WooCommerce API, EDD API Endpoints

Rule Name: Add the following in the Rule Name section Cache Bypass — WP Admin Paths, WooCommerce API, EDD API Endpoints

Rule Expression: Add the following expression inside the expression builder section.

(
  http.host eq "example.com" and
  (starts_with(http.request.uri.path, "/wp-admin") or starts_with(http.request.uri.path, "/wc-api/") or starts_with(http.request.uri.path, "/edd-api/"))
)

Cache Status: Set it to Bypass Cache.

Rule 2 ➜ Cache Bypass — XML, XSL & PHP Files

Rule Name: Add the following in the Rule Name section Cache Bypass — XML, XSL & PHP Files

Rule Expression: Add the following expression inside the expression builder section.

(
  http.host eq "example.com" and
  (http.request.uri.path contains ".xsl" or http.request.uri.path contains ".xml" or http.request.uri.path contains ".php")
)

Cache Status: Set it to Bypass Cache.

Rule 3 ➜ Cache Bypass — Default Bypass Cookies

Rule name: Add the following in the Rule Name section Cache Bypass — Default Bypass Cookies

Rule Expression: Add the following expression inside the expression builder section.

(
  http.host eq "example.com" and
  (http.cookie contains "wordpress_logged_in_" or http.cookie contains "comment_" or http.cookie contains "woocommerce_" or http.cookie contains "wordpressuser_" or http.cookie contains "wordpresspass_" or http.cookie contains "wordpress_sec_" or http.cookie contains "yith_wcwl_products" or http.cookie contains "edd_items_in_cart" or http.cookie contains "it_exchange_session_" or http.cookie contains "comment_author" or http.cookie contains "dshack_level" or http.cookie contains "auth_" or http.cookie contains "noaffiliate_" or http.cookie contains "mp_session" or http.cookie contains "xf_" or http.cookie contains "mp_globalcart_") and
  not http.request.uri.path contains "."
)

Cache Status: Set it to Bypass Cache.


Optional Rule

Rule 4 ➜ Cache Eligible Requests & Ignore Unnecesary Query Params from cacheKey

Rule name: Add the following in the Rule Name section Cache Eligible Requests & Ignore Unnecesary Query Params from cacheKey

Rule Expression: Add the following expression inside the expression builder section.

(http.host eq "example.com" and not starts_with(http.request.uri.path, "/wp-admin") and not starts_with(http.request.uri.path, "/wp-json/") and not starts_with(http.request.uri.path, "/wc-api/") and not starts_with(http.request.uri.path, "/edd-api/") and not http.request.uri.path contains ".xsl" and not http.request.uri.path contains ".xml" and not http.request.uri.path contains ".php" and not http.request.uri.query contains "s" and not http.cookie contains "wordpress_logged_in_" and not http.cookie contains "comment_" and not http.cookie contains "woocommerce_" and not http.cookie contains "wordpressuser_" and not http.cookie contains "wordpresspass_" and not http.cookie contains "wordpress_sec_" and not http.cookie contains "yith_wcwl_products" and not http.cookie contains "edd_items_in_cart" and not http.cookie contains "it_exchange_session_" and not http.cookie contains "comment_author" and not http.cookie contains "dshack_level" and not http.cookie contains "auth_" and not http.cookie contains "noaffiliate_" and not http.cookie contains "mp_session" and not http.cookie contains "xf_" and not http.cookie contains "mp_globalcart_")

Cache Status: Set it to Eligible for cache.

Cache Key:

In this section enable the following options:

  • Cache deception armor
  • Ignore query string
  • Ignore query string order

Finally the cache rule should look something like this ☟ Cache Eligible Requests & Ignore Query Params from cacheKey Rule Screenshot

Very Important Note Badge
Once you add this fourth cache rule, Cloudflare will simply ignore the unnecessary query strings when checking the cached contents of your website.
If you check the above cache rule, you will see that the s query param which is commonly used in WordPress websites for search functionality has already been whitelisted so that Cloudflare system does not ignore that query parameter.
So, if you provide an URL e.g. https://example.com/some-page/?s=some+search+phrase in this case Cloudflare system will NOT ignore the s query param so that your search functionality works properly.
If you have more query params on which your website is dependent on and you do not want Cloudflare to ignore them, then you can check the above screenshot and add new query params below the s param to whitelist them exactly the same way I have whitelisted the search query param.
Alternatively if you enter https://example.com/some-page/?fbcid=123&foo=bar&something=test, Cloudflare will simply ignote the ?fbcid=123&foo=bar&something=test part and check if https://example.com/some-page/ is cached, if so, return the cached content.
This will help increasing the Cache HIT ratio of your website as most unnecesarry and marketing query params will be ignored by Cloudflare.

Once you have all these Cache Rule added to your Cloudflare dashboard, you can proceed to the Step 2 below.

Step 2 — Enabling Remove Cache Buster Query Parameter option in the plugin settings & Purge the whole Cloudflare Cache

Inside the Super Page Cache for Cloudflare plugin settings, go to the Other tab and scroll down. You will see an option named Remove Cache Buster Query Parameter.

plugin settings to enable

Enable that option and save the plugin settings. Then all you need to do is to make sure that you have force purged everything from the Cloudflare Cache.

That's it. Now you have the Cloudflare CDN Level Page Caching with the Cache Everything Page Rule without any cache buster query parameter (e.g. ?swcfpc=1). Also if you have added the fourth Cache Rule then your cache HIT ratio will also increase dramatically as Cloudflare will now ignore the query strings when checking if the URL is already cached. Enjoy... 🥂🍾🥳🎉

P.S.: Make sure you have enabled Smart Tiered Cache inside your Cloudflare Dashboard for the highest cache HIT ratio.

@ofmarconi
Copy link

AMAZING! 👍

@ossplus
Copy link

ossplus commented Mar 18, 2023

For Rule 1, do we need to bypass the /wp-json/ ?

@isaumya
Copy link
Author

isaumya commented Mar 20, 2023

For Rule 1, do we need to bypass the /wp-json/ ?

The rule that I have added above, /wp-json/ is not mentioned there. But if you want you can add it. The reason behind not adding /wp-json/ inside the cache rules is because if needed you can bypass caching for the /wp-json/ paths from the plugin settings.
wp-json cache bypass
But if you like to bypass the cache for WP JSON endpoints via cache rules, you can add that check.

@NisbetHubbard
Copy link

NisbetHubbard commented May 4, 2023

For those migrating from cache buster, might be helpful to mention here the option to turn on 301 redirect in case the query parameter already got indexed by some crawler, as a crawler can still bypass the cache by using the buster even after doing step 2.

@isaumya
Copy link
Author

isaumya commented May 4, 2023

Hi @gittehubbard,
You can definitely enable the 301 redirect in the plugin settings, but the use case you are mentioning is not a widespread thing, which is why it is not mentioned above and enabled by default. Besides anyone who is installing this plugin for the first time, they can just start with the above cache rules and don't have to worry about cache buster.

@imflexwala
Copy link

Thank you for sharing this amazing guide @isaumya
I was having issues with logged-in customers in woocommerce, it seems fixed now after applying this.

@sumon1068
Copy link

Whay do we need Rule 4?
We already have a page rule that says "Cache Everything".

Cache rule 1,2&3 says don't cache these. So the rest should be cached automatically for the "Cache Everything" page rule. So why do we need cache rule 4?

And from the plugin settings, I've already checked Don't cache the following dynamic contents: Search Pages (is_search) - (recommended). So, do we need to whitelist s query parameter again?

The fact is, my website uses a lot of query parameters. Super Socializer plugin, custom plugin: query multiple taxonomies, MailPoet plugin etc use query parameters. Identifying which query parameters to whitelist will be a very tough job. Instead, finding which qeury parameter to ignore is easy for me. As for example, I am using a Transform Rule to rewrite query parameter fbclid=.

So can I skip Rule 4?

@isaumya
Copy link
Author

isaumya commented May 5, 2023

Hi @sumon1068,
As I have mentioned above Rule 4 is definitely optional. But adding it would give you a better caching experience with a few more added benefits like cache deception armor, ignoring unnecessary query params from cacheKey etc. So, it's totally up to you if you would like to use Rule 4 or not. But using it will give you a better caching experience. Please read above, I've explained everything in great detail.

@NisbetHubbard
Copy link

Hi @gittehubbard,
You can definitely enable the 301 redirect in the plugin settings, but the use case you are mentioning is not a widespread thing, which is why it is not mentioned above and enabled by default. Besides anyone who is installing this plugin for the first time, they can just start with the above cache rules and don't have to worry about cache buster.

Thanks! Edited to reflect the specific use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment