Super Page Cache for Cloudflare

Yes. This is the main purpose of this plugin.

No, this is a caching plugin. To perform other page optimizations you can use it together with other performance plugins.

The purpose of this plugin is to get you the lowest possible response times (TTFB) by using Cloudflare as a page caching system, while maintaining full control of the cache.

It is a cache buster. Allows you, while logged in, to bypass the Cloudflare cache for pages that could be cached.

It is added to all internal links for logged in users only. It is disabled in Worker mode.

Yes you can by click on Reset all button.

Cloudflare does not add in cache pages with cookies because they can have dynamic contents. If you want to force this behavior, strip out cookies by enabling the option Strip response cookies on pages that should be cached.

Fallback Cache is an option to generate static HTML version of the webpages inside your site. This is a great option and can increase your site speed dramatically. The way Cloudflare works is that it will only cache a page to it's global CDN network if it has received any request for those pages. So, if you don't have fallback cache, for the first few requests, your server will be executing the pages and sending the HTML to the user, which increases slowness and latency.

Our fallback cache system follows the same standard that Cloudflare follows when it caches a page to it's CDN edge. This way we generate the HTML version of the webpage before an user has requested for that page. By doing this, when any user access the webpage for the first time, the page loads super fast as it is already loading a rendered HTML rather than waiting for the server to generate HTML and pass that to the users.

Our fallback cache system works way better than any other disk cache system and plugins out there in the market. In short now you don't need to install any other caching plugin in conjunction with Super Page Cache for Cloudflare, as the plugin can now handle Cloudflare caching and disk caching.

The preloader is a simple crawler that is started in the background and aims to preload pages so that they are cached immediately.

Once the preloader is enabled, you need to specify which preloading logic among those available to use. You can choose a combination of options (sitemaps, wordpress menus, recent published posts, etc ..).

It is also possible to automatically start the preloader when the cache is cleared.

In order to avoid overloading the server, only one preloader will be started at once. It is therefore not possible to start more than one preloader at the same time. Furthermore, between one preload and the other there will be a waiting time of 2 seconds.

If you want to run the preloader at middle of the night when you have low users, you can run the preloader over CRON job as well.

If the Purge HTML pages only option is enabled, clicking on the PURGE CACHE button only HTML pages already in cache will be deleted from Cloudflare's cache.

If for some reason you need to delete static files (such as CSS, images and scripts) from Cloudflare's cache, you can do so by clicking on Force purge everything

This is a Cloudflare authentication error. If you chose the API Key as the authentication mode, make sure you have entered the correct email address associated with your Cloudflare account and the correct Global API key (not your Cloudflare password!).

If you are chose the API Token as the authentication mode, make sure you have entered the correct token, with all the required permissions, and the domain name exactly as it appears in your Cloudflare account.

Also make sure you haven't entered the API Token instead of the API key or vice versa

Login to Cloudflare, click on your domain and go to Page Rules section. Check if a Cache Everything page rule already exists for your domain. If yes, delete it. Now from the settings page of Super Page Cache for Cloudflare, disable and re-enable the cache.

If you are using an API Token, check that you entered the domain name exactly as on Cloudflare

Maybe you have some extra newline or space in other PHP files executed before advanced-cache.php such like must-use plugins or wp-config.php.

Check those files. Try the following:

1. If you have any code inside mu-plugin take them out of that folder. Check your server error log and test to see if you are getting the header errors still.
2. If not then check the codes inside the PHP files and see if any of them has an extra newline or space at the end of the script. If they have delete those new lines and spaces and test.
3. If still doesn't work check if any of the scripts inside mu-plugins have print, echo, printf, vprintf etc. in the code. For more details check: https://stackoverflow.com/a/8028987/2308992

In short, the problem is not coming from this plugin but some mu-plugin is sending the header before advanced-cache.php can. That's causing the issue. We have thoroughly tested this.

Exclude the custom login URL by adding it into the textarea near the option Prevent the following URIs to be cached, then save, purge the cache, wait 30 seconds and retry.

Yes but if you are using a LiteSpeed Server version lower than 6.0RC1, disable the option Overwrite the cache-control header for Wordpress's pages using web server rules. You can keep this option enabled for Litespeed Server versions equal or higher then 6.0RC1

If you are using a Kinsta hosting, you can integrate this plugin to work with Kinsta Server Level Caching and to ensure when you Purge Cache via this plugin, it not only purges the cache on Cloudflare but also on Kinsta Cache. You can enable this feature by going to the "Third Party" tab of the plugin settings and enabling the "Automatically purge the Kinsta cache when Cloudflare cache is purged" option. It is also recommended that if you are taking advantage of the Kinsta Server Caching (Recommended), please ensure that the Fallback Cache system provided by this plugin is turned OFF.

After purging the cache from our plugin, it gets deleted from both Kinsta & Cloudflare Cache. Now when you visit the webpage for the first time after purging the cache, you will get cache response headers as MISS/EXPIRED etc. for both Cloudflare and Kinsta cache.

At this point after receiving the first request both Cloudflare & Kinsta caches the page on their own platforms respectively. But do note that when Cloudflare is caching the first request at this point the x-kinsta-cache header is of status MISS. For the second request when Cloudflare serves the page from it's own CDN Edge servers without sending the request to the origin server, it keeps showing the x-kinsta-cache cache header as MISS. Because when Cloudflare cached the page the response header was MISS but Kinsta caching system has already cached it upon receiving the first request.

Now if you purge the Cloudflare cache only (on Cloudflare dashboard) or enable development mode in the Cloudflare dashboard so that the request doesn't get served from Cloudflare CDN, you will see the x-kinsta-cache showing as HIT, because this time the request is going to your origin server and you are seeing the updated response headers that is being served by the server.

Yes you can! You have only to disable its page caching functionality. To do this:

1. Go to Litespeed Cache > Cache
2. Click on OFF near Enable Cache
3. Click on Save Changes button

Then:

1. Enter to the settings page of this plugin
2. Click on Third Party tab
3. Scroll to Litespeed Cache Settings section
4. Enable the option Automatically purge the cache when LiteSpeed Cache flushs all caches
5. Purge the cache

Yes you can! It is highly recommended to enable the option Enable 404 fallbacks of Autoptimize.

Yes you can! Please follow these steps mentioned in this GitHub Gist. This will guide you to do all the things necessary in order to use WP Rocket with this plugin. Here is a summery of what you need to do:

1. Disable WP-Rocket and make sure no advanced-cache.php files of other plugins are into wp-content directory
2. Upload the must use plugin code (inside /wp-content/mu-plugins/ folder) provided in the GitHub Gist (link given above).
3. Enable this plugin
4. Enable the Fallback Cache option (If you want to use disk level fallback cache)
5. Click on Third Party tab
6. Scroll to WP-Rocket Cache Settings section and enable the Disable WP Rocket page cache option
7. Purge the cache
8. Enable WP-Rocket again
9. Purge WP-Rocket cache

No. The support for these plugin was removed because you can use the fallback cache option of this plugin if you want to use a standard page cache behind Cloudflare.

In order to avoid conflicts, it is strongly recommended to use only this plugin as page caching system.

Yes but you don't need it. If you want to use a standard page cache behind Cloudflare, enable the fallback cache option of this plugin.

In order to avoid conflicts, it is strongly recommended to use only this plugin as page caching system.

This should never happen. If it happens, it is because the value of the Cache-Control response header is different from that of the X-WP-CF-Super-Cache-Cache-Control response header (make sure it is the same).

If you are using LiteSpeed Server version lower than 6.0RC1, make sure the Overwrite the cache-control header for Wordpress's pages using web server rules option is disabled. If not, disable it, clear your cache and try again. You can keep this option enabled for Litespeed Server versions equal or higher then 6.0RC1

If you are not using LiteSpeed Server and you are using this plugin together with other performance plugins, enable the Overwrite the cache-control header for Wordpress's pages using web server rules option, clear the cache and try again.

If this doesn't work, you can always choose to activate the Force cache bypassing for backend with an additional Cloudflare page rule option or to change the caching mode by activating the Worker mode option.

First of all enable the log mode and check if in the log file, after clicking on the update button on the edit page, you see the information about the cache purging.

If so, good news: the plugin is working correctly. If not, open a ticket on the support forum.

If you have enabled the Fallback cache, make sure you have also enabled the option Automatically purge the fallback cache when Cloudflare cache is purged.

If you are using Varnish cache, make sure you have also enabled the option Automatically purge Varnish cache when the Cloudflare cache is purged.

Disable any other page caching plugins or services. Only use this plugin to cache HTML pages.

If you still don't see the changes despite everything, the problem is to be found elsewhere. For example wrong configuration of wp-config.php.

In very rare cases, it may happen that some third-party plugin stores the cache buster parameter in the database, and therefore this is then also displayed to users who are not logged in and therefore to search engine bots.

If this happened on your site, enable the SEO redirect inside the plugin settings page under the Others tab. This will auto redirect any URLs which has swcfpc=1 in it to it's normal URL when any non-logged in user clicks on that link, avoiding duplicate content problems.

Some page builders might copy the admin side links and show that on the front end for all users. This happens because these page builders do not follow the standard WordPress coding guidelines to fetch URLs and instead copy hard code URLs. If you are facing this issue, you can easily fix this by enabling the SEO redirect option inside the plugin settings page under the Others tab. This will auto redirect any URLs which has swcfpc=1 in it to it's normal URL when any non-logged in user clicks on that link.

There are a couple of things that can cause this issue and tell Cloudflare not to cache everything. If you are facing this issue, please check the following this:

• Make sure that Development Mode is NOT enabled for your domain inside Cloudflare.
• Make sure you have the orange cloud icon enabled inside the Cloudflare DNS settings for your main domain A record and WWW record.
• Make sure you do not have any other page rules that might conflict with the Cache Everything rule
• Make sure you do not have any Cloudflare Worker code deployed that might overwrite the normal cache policies
• Make sure you don't have any plugins which might be adding a lot of unnecessary Cookies in your request header for no reason. If you have any cookie consent plugin or any similar things, try disabling those plugins and check again. You can also enable the Strip response cookies on pages that should be cached option under the Cache tab to see if this resolves your issue. If it does, that means there are plugin which is injecting cookies into your site header and when Cloudflare sees these Cookies, it think that the page has dynamic content, so it doesn't cache everything.

In most cases you don't need to enable the cURL mode for fallback cache. If you don't enable the cURL mode, the plugin will use the standard WordPress advanced-cache.php method to generate the fallback cache. This system works well in almost all the cases, also this cache generation mechanism is very fast and don't eat much server resource. On the other hand the cURL mode is useful in some edge cases where the advanced-cache.php mode of fallback cache is unable to generate proper HTML for the page. This is rare, but the cURL option is given just for these edge cases.

One of the benefit of the cURL mode is that as it uses server level cRUL instead of advanced-cache.php to generate the page cache, the cache files comes out very stable and without any issues. But then again if your enable the cURL mode, that means cURL will fetch every page of your website (which are not excluded from fallback cache) to generate the fallback cache and each cURL request is going to increase some server load. So, if you have a small to medium site with not many pages, you can definitely use the cURL mode of fallback cache. But for large high traffic website, unless you have more than enough server resource to handle so many cURL requests, we will recommend stick to using the default advanced-cache.php option which works flawlessly anyway.

Cloudflare Workers is an amazing technology which allows us to run complicated logical operations inside the Cloudflare edges. So, basically before Cloudflare picks up the request, it passes through the Cloudflare worker and then we can programmatically tell Cloudflare what to do and what not to do. This gives us great control over each and every request and how Cloudflare should handle them.

The Page Rule option of Cache Everything works perfectly in almost every cases but in some situations due to some server config or other reasons, the headers that this plugin sets for each requests, does not get respected by the server and gets stripped out. In those edge case scenarios Cloudflare Worker mode can be really helpful over the page rules mode.

So, in terms of speed, you might not see a difference but the Worker mode is there just for the cases when the page rule mode is not working correctly across the whole website (frontend & backend).

Yes & No. It depends on how many visitors your site have. Cloudflare Workers have a free plan which allows 100,000 requests/day for FREE. But if your site has more requests than that per day, then you need to opt for the paid plan of $5/month which will give you 10 Million Requests/month and after that $0.50 per additional 1 Million requests.

Please note that, all requests first get intercepted by Cloudflare Worker before Cloudflare decide what to do with that request, so whether your requests gets served from Cloudflare CDN Cache or from origin, it will be counted towards your Worker usage limit.

If you have a small to medium site, you can easily use Cloudflare Worker without hesitating about payment as you will not get pass the free quota, but as you grow, and if you still want to use the Cloudflare Workers, you might have to pay for it. Cloudflare Workers are so much more and has so much power that if you are truly taking advantage of the Cloudflare Workers, your can do a lot of cool things. So, in short if you have a big high traffic site and you don't want to pay extra for the Cloudflare Workers, you should just stick with the Page Rules option.

After you enter the Cloudflare API details, we push our worker code using Cloudflare API to your Cloudflare account. You can find our Cloudflare Worker code inside the plugin's /assets/js/worker_template.js path.

Yes. Commands list: wp cfcache

That is a super advanced option to use Cache Everything Cloudflare page rules without the swcfpc cache buster query parameter. This option is only for super advanced users who are confortable adding custom rules in their Cloudflare dashbord. If you are that person, this option probably will not be a good fit for you.

Also when using this option please keep in mind that some rules can only be implemented in Cloudflare Business and Enterprise account users. So, if you are a CLoudflare Free or Pro plan users, you might not be able to implement some rules.

Please check this implementation guide which comes all types of Cloudflare accounts before enabling this option.

Without implementioned these rules properly if you enable this option, it will break the cache functionality of your website.

Yes you can by adding the PHP constant SWCFPC_CACHE_BUSTER to your wp-config.php

Yes you can use the following PHP constants:

• SWCFPC_CACHE_BUSTER, cache buster name. Default: swcfpc
• SWCFPC_CF_API_ZONE_ID, Cloudflare zone ID
• SWCFPC_CF_API_KEY, API Key to use
• SWCFPC_CF_API_EMAIL, Cloudflare email to use (API Key authentication mode)
• SWCFPC_CF_API_TOKEN, API Token to use
• SWCFPC_PRELOADER_MAX_POST_NUMBER, max pages to preload. Default: 50
• SWCFPC_CF_WOKER_ENABLED, true or false
• SWCFPC_CF_WOKER_ID, CF Worker ID
• SWCFPC_CF_WOKER_ROUTE_ID, route ID
• SWCFPC_CF_WOKER_FULL_PATH, full path to worker template to use
• SWCFPC_CURL_TIMEOUT, timeout in seconds for cURL calls. Default: 10
• SWCFPC_PURGE_CACHE_LOCK_SECONDS, time in seconds for cache purge lock. Default: 10
• SWCFPC_PURGE_CACHE_CRON_INTERVAL, time interval in seconds for the purge cache cronjob. Default: 10
• SWCFPC_HOME_PAGE_SHOWS_POSTS, if the front page a.k.a. the home page of the website showing latest posts. Default: true (bool)

Actions:

• swcfpc_purge_all, no arguments. Fired when whole caches are purged.
• swcfpc_purge_urls, 1 argument: $urls. Fired when caches for specific URLs are purged.
• swcfpc_cf_purge_whole_cache_before, no arguments. Fired before purge the Cloudflare whole cache.
• swcfpc_cf_purge_whole_cache_after, no arguments. Fired after the Cloudflare whole cache is purged.
• swcfpc_cf_purge_cache_by_urls_before, 1 argument: $urls. no arguments. Fired before purge the Cloudflare cache for specific URLs only.
• swcfpc_cf_purge_cache_by_urls_after, 1 argument: $urls. no arguments. Fired after the Cloudflare cache for specific URLs only is purged.

Filters:

• swcfpc_bypass_cache_metabox_post_types, $allowed_post_types (Array). You can use this filter to ensure that the bypass cache metabox is also shown for your own custom post types. Example code link: https://wordpress.org/support/topic/disable-page-caching-for-specific-pages-with-cpt/#post-16824221
• swcfpc_fc_modify_current_url, $current_uri (string). You can use this filter to modify the url that will be used by the fallback cache. For example you can remove many query strings from the url. Please note that this filter will return the URL without the trailing slash.
• swcfpc_cache_bypass, one arguments. Return true to bypass the cache.
• swcfpc_post_related_url_init, $listofurls (array), $postId. Fired when creating the initial array that holds the list of related urls to be purged when a post is updated. Show return array of full URLs (e.g. https://example.com/some-example/) that you want to include in the related purge list.
• swcfpc_normal_fallback_cache_html, [One Arguments] : $html. This filter is fired before storing the page HTML to fallback cache. So, this gives you the ability to make changes to the HTML that gets saved within the fallback cache. This filter is fired when the fallback cache is generated normally via the advanced-cache.php file.
• swcfpc_curl_fallback_cache_html, [One Arguments] : $html. This filter is fired before storing the page HTML to fallback cache. So, this gives you the ability to make changes to the HTML that gets saved within the fallback cache. This filter is fired when the fallback cache is generated normally via cURL method.

Unfortunately, Cloudflare allows one worker per route. So, as long as our worker is setup in the main route, you cannot use your own worker code in the same route. But you can take advantage of SWCFPC_CF_WOKER_FULL_PATH PHP constant to provide the full path of your own custom JavaScript file.

In this way you can take a look at inside the plugin's /assets/js/worker_template.js path and see the Worker code we are using by default. Then you can copy that worker template file in your computer and extend it to add more features and conditionality that you might need in your project. Once you are done with your Worker code, you can simply point your custom Worker template JavaScript file inside wp-config.php using the SWCFPC_CF_WOKER_FULL_PATH PHP constant and the plugin will use your Worker file to create the worker in your website route instead of using the default Worker code. Here is an example of how to use the PHP constant inside your wp-config.php. Please make sure you provide the absolute path of your custom Worker file.

define('SWCFPC_CF_WOKER_FULL_PATH', '/home/some-site/public/wp-content/themes/your-theme/assets/js/my-custom-cf-worker.js');

Please note that for 99.999% of users the default Worker code will work perfectly if they choose to use the Worker mode over the Page Rule mode. This option will be provided only for Super Advanced Knowledgeable Users who know exactly what they are doing and which will lead to what. General users should avoid tinkering with the Worker Code as this might break your website if you don't know what you are doing.

Yes. To purge the whole cache use the following PHP command:

do_action("swcfpc_purge_cache");

To purge the cache for a subset of URLs use the following PHP command:

do_action("swcfpc_purge_cache", array("https://example.com/some-page/", "https://example.com/other-page/"));