In my WordPress sites with static content, I prefer to use
Rocket Loader: OFF
Always Online: OFF
Security Level: High
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.
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.
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.
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.
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.
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)
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.
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.
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.
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”
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:
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.