W3 Total Cache + Cache Everything

Hello,

I use W3 Total Cache and Cloudflare (first time) duo.
Cloudflare settings are as follows:

Browser Cache TTL: Respect Existing Headers

Page Rules:

domaincom/wp-admin*
Cache Level: Bypass, Disable Performance
domaincom/en/wp-admin*
Cache Level: Bypass
domaincom/*
Cache Level: Cache Everything, Edge Cache TTL: a month

My questions:

  • How should the settings in the Cloudflare section of the W3 Total Cache plugin be? Or is it necessary?

Thank you.

1 Like

Hi,

In my WordPress sites with static content, I prefer to use

/wp-*
Rocket Loader: OFF
Always Online: OFF
Security Level: High
Disable Apps

Cache Level: Bypass should not be used; the position of this rule before the Cache Everything rule prevents the latter from being executed.

The wp-* path, as opposed to /wp-admin*, will make sure that other standard WP files aren’t cached, like wp-login.php, wp-json.php etc. And because it doesn’t include the Cache Level: Bypass, the static files under /wp-content will still be cached by default.

Make sure you purge all after making changes to your page rules.

As for the new articles being published, you should use the Cloudflare plugin and its Automatic Cache Management feature, to make sure the cached pages are purged from CF datacenters when content is updated. Also, you should make sure to purge the home page when you add stories. Or create a special page rule for it with Edge TTL set to a few hours.

Hi @floripare

Thank you for the detailed information.

Don’t you suggest the page rules I share?

I am not already using the Rocket Loader and Always Online features. All we want is to reach the “highest” speed. Don’t I have to use the “Everything Cache” rule for this?

This should not be needed as your language when logged in is used from your setting, not the path you are using. So all logins normaly are going through domain.com/wp-admin (without /en/)

I disagree on that. I have it placed also BEFORE the Cache-Everything rule, and thats the only way it perfectly works. If I have understood it wrong please correct me. Also this works good with Cache Level: Standard but bypass also worked perfectly. but then ignores the standard settings by the origin Server.

Now the CloudFlare Docs/Supportpage recommends “Bypass Cache on Cookie”

But that feature is just available for Enterprise customers what is a bit strange as Wordpress is mostly used at low-budget projects… well.

I created my rules like this:

*domain.com/wp-admin* (this applies to ALL WP-Instances on your Domain)
Cache Level: Standard, Disable Performance, Cache Deception Armor: On, Security Level: High

https://www.domain.com/*
Disable Security, Cache Level: Cache Everything, Browser Cache TTL: a year, Edge Cache TTL: a month

Works good so far. May this helps you.

1 Like

Your rules are fine. I just suggested an alternative (perhaps I wasn’t clear) that you could use, instead of your rules for /wp-admin*:

A rule for /wp-* that would apply to the backend (/wp-admin*) as well as to other standard WP assets you don’t want cached, such as wp-login.php and wp-json.php.

So:

URL: /wp-*
Settings:
Rocket Loader OFF (many plugins have issues with RL in the backend)
Always Online OFF (you don’t want this in the backend)
Disable Apps (you probably don’t need apps in the backend, may become annoying)
Security Level: High (important for the /wp-admin/ section, but you need to change this in case you ever implement a I’m Under Attack Mode for the domain).

But since this /wp-* rule would also apply to /wp-content* area, where your static assets (images, CSS, JS etc) are, you should not in this case use the Cache Level: Bypass setting (or any Cache Level for that matter).

When you place this rule before (above) the rule for Cache Everything, it will prevent caching of the backend as the Cache Everything rule will never trigger for the backend URLs.

I hope the explanation above is clearer than my first attempt. If the Cache Everything rule is never triggered for the URLs in the first rule, this first rule doesn’t need a Cache Level: Bypass setting, as HTML/PHP content by default is not cached by Cloudflare.

1 Like

Got it. That makes sense!

Cache Level: Standard should be fine as it respects the origin Servers settings?
I anyway used Cache Level Standard.

But to solve that issue you can create a different (first rule) Page-Rule with /wp-content* that will again have Cache Everything. That would solve it.

That would make the perfect Rules for Wordpress:

1 Rule

*domain.com/wp-* (this applies to ALL WP-Instances on your Domain)
Disable Performance
Cache Deception Armor: On
Security Level: High

2 Rule

https://www.domain.com/*
Cache Level: Cache Everything
Disable Security
Browser Cache TTL: a year
Edge Cache TTL: a month

#EDITED

1 Like

The main reason I suggested the /wp-* was exactly to spare one rule. The static files under /wp-content* are cached by default, so why waste a rule for that? If you drop your first rule, you should be fine, as the Cache Level: Standard setting in your 2nd rule, though not needed, will not cache the PHP/HTML content of the backend anyway, and the static files will be cached with or without that setting.

1 Like

I will just edit the other post.

Not to sure about this. But it depends on how exactly CF works. If we imagine the URL: https://www.domain.com/wp-content/example.jpg

This matches the first rule and first rule applies all the options which it does have.
Second rule also matches and it applies all its missing options.

Now as “Cache Level” is not set for this, will the second rule set it (Cache Everything) or not?
If a rule applies will it stop this from the lower rules to be executed or will they be able to add all the other (missing) parameters which are not yet set?

I thought it will look like this (on example for the 2 Rules I mentioned above)

https://www.domain.com/wp-content/example.jpg
Disable Performance (from 1 rule)
Cache Deception Armor: On (from 1 rule)
Security Level: High (from 1 rule)
Cache Level: Cache Everything (from 2 rule)
Browser Cache TTL: a year (from 2 rule)
Edge Cache TTL: a month (from 2 rule)

Or is it like this:
https://www.domain.com/wp-content/example.jpg
Disable Performance (from 1 rule)
Cache Deception Armor: On (from 1 rule)
Security Level: High (from 1 rule)

Hi,

Are the following rules sufficient and correct?

1- *domain.com/wp- *
Security Level: High, Cache Deception Armor: On, Disable Performance On

2- domain.com/*
Disable Security, Cache Level: Cache Everything, Edge Cache TTL: a month

Also W3 Total Cache settings like this:

Screen Shot 2020-06-02 at 12.17.58

What do you think about this order and settings?

Yes, only one rule applies to any given request, so the order of page rules matter. You need to put the more specific page rules at the top, the most generic at the bottom.

In your given example, if 1 Rule applies, the request will never match any other rules down the list… For any request that doesn’t match this rule, the following rule will be processed.

For the purpose of caching the HTML pages generated by WP, and not caching the backend, they should be sufficient and correct, provided that your site does not offer content that is login-dependent in its front end.

1 Like

The order and settings appear to be correct.

Though I normally disable apps for the backend pages (wp-admin), I wouldn’t disable them in a preview rule, as I’d want to preview pages as they appear to the final user.

1 Like

Hello again,

I realized that these rules do not affect the installation of wordpress in the subfolder. The installation I mentioned is domain.com/en/wp-admin. I also used 3 rules in the Free plan. Should I buy 5 more rules? Or do you have a suggestion?

A rule with *domain.com/*wp-* should solve the problem.
ALso: for Wordpress you can run Multisite-Mode. Then you just have one installation and can manage multiple installations. Then you dont need more rules.

1 Like

As a point of interest: we asked a very similar question a month ago. We got conflicting answers on the forum, then since we are a Pro client, asked Cloudflare support To c;arify. Two different Cloudflare support techs also gave answers that conflicted each other! In one case, conflicted with their own docs. Even this thread has conflicting opinions.

We have been engaged in a back and forth with support about this subject for about a month.
It is not resolved.

It seems to be something of a mystery where no one knows the true answer.

Most of us who use Wordpress have public content (Landing pages, home pges) that requires No login to view,
AND have content only ‘members’ can view. (ALL the sites we manage are setup that way.)

Most of us are using a cache plugin of some sort.

And if you want your site ranked in any way by Google, your pages need to load fast.

Yet, there seems to be no definitive ‘this is what you do’ guide for Wordpress sites like ours. Even their Cloudflare Wordpress plugin is out of date - is not even tested for the last several versions of Wordpress.

Very few of is are Enterprise level with Cloudflare. So docs that teach you to use the Cookie Bypass with caching plugins are useless. Free users only get 3 page rules, so that is a severe constraint.

I suspect every Wordpress site user needs definitive, accurate answers on this subject, but I am not sure there are Wordpress experts on their tech team. Or at least not ones addressing this question. If I learn anything useful - and exceptionally accurate - I will post it. :slight_smile:

Sid B.

1 Like

Hello Ayberk,

Is your server LiteSpeed server? Why not use LiteSpeed Cache?

I wonder :slight_smile:

https://www.litespeedtech.com/products/cache-plugins/wordpress-acceleration/compare

https://www.litespeedtech.com/products/cache-plugins/wordpress-acceleration

Thats why they are called “opinions” there is no right or wrong. It all depends on what you need and depends on the individual needs and setups.

Then you have not understood how this CloudFlare Plugin is working and what it does. This CloudFlare Plugin - not like other Plugins - does not depend on WordPress as it in some kind is “seperated” as it just uses hooks and an API to communicate with CloudFlare Dashboard.
This means: you dont need to update this Plugin unless something really really big changes in WordPress. So please dont care about the “outdated WordPress Plugin”

True.

There are different ways to solve things and if you accuse someone to say something what stands in conflict to something else could you proofe that or at least tell us what exactly was is conflict with what? Things like this are said very fast.

Just big companies does so yes I was surprised aswell that they recommend this for normal customers. But this again just applies to “Cache Everything” not to a normal dynamic setup.

There is not need for this in CloudFlare. WordPress experts should be in a WordPress Forum.

Btw: please dont get this wrong I’m not a CloudFlare worker NOR in any way related/sponsored/paid by CloudFlare.

Also: if there are different approaches this may is because people do have different needs. If you want to use the function “Cache Everything” from CloudFlare then this thread is right, if not, your in the wrong thread. The point is: everyone wants something different, thats why there are different solutions.

Just try them and decide on your own which fits best your personal needs! Here in the forum you will not get any very dedicated configuratiosn just for you.

That is exactly the problem that I have with WordPress and most of their users. They want to solve complex and variable problems with just one easy click and at zero cost. These things does not fit very well.
See the chart/picture below:

Why not using [insert caching method here]?
This thread is about W3 Total Cache. Also never trust any “comparissons” on the page of the vendor! Never. They are never trustfull.

On a Page which “litespeed” owns another Caching method will never “win” or look good. Please use independend sites/benchmarks.

1 Like

Thanks,

This worked.

1 Like

You are responding to commentary, but have not seen the questions or the response I actually had with CloudFlare support.

When you give all support people answering questions the exact same information on your configuration, and get CONFLICTING ANSWERS - and I do NOT mean “opinions” I mean 2 people where one says TO use a feature/setting, and another telling you NOT to set it or use it.

And I strongly DISAGREE - you can not give good advice about how to interface with a complicated system like WordPress if you do not understand how WordPress works (for example, not all content in WordPress is actually ‘dynamic’ in nature, as CloudFlare defines it)

Obviously you do not understand WordPress if you imply that using an untested plugin is a good idea. The fact that it IS a plugin means it is NOT ‘unconnected’ to WordPress. Their plugin does, in fact, make changes to the WordPress site based on the connection to CloudFlare/API. THAT kind of plugin needs to be tested.

And I personally do not care for generalizations statements like

”…the problem that I have with WordPress and most of their users…”

There is enough of that none sense going around these days.

Us “WordPress Users” deserve to be told how best and correctly to interface with & use the Cloudflare service with our type of system, especially when we are paying to use CloudFlare.

Sid