Cache everything with WordPress

Try it out.

We have a suggestion to solve this issue, let’s imagine your site usually served as www.DOMAIN.TLD
Any log in form should submit via POST, and POST requests bypass cache by default on Cloudflare, so, the response for the login submission will not be cached.
So… upon successful login, you could redirect the user to another subdomain, let’s say members.DOMAIN.TLD and from there on the logged in user would be using a different subdomain.
You setup a page rule for www.DOMAIN.TLD to “cache everything” and for members.DOMAIN.TLD you just leave it as “standard”.

We believe you would achieve desired result with this setting, let us know your thoughts.
Hope it helps.
Kind regards

In theory, this is a great idea. In practice though, doesn’t WordPress
make this fairly difficult? The /wp-admin/ panels all tend to generate
URLs that link the user back to the main domain, at least in my limited

There might be solutions or plugins to manage this, I haven’t looked.

You might get into all kinds of snafus with cookie and session variables. Have you tried the Comet Cache wordpress plugin? It saves wordpress output as an html file. Subsequent requests bypass wordpress core and sends out the saved HTML. And it’s smart enough to not do that if someone is logged in - in which case that user gets fresh content from wordpress (slower, but you can’t get around that). In my experience, TTFB is 10x faster with this plugin.

@Jules We got that. Using a server side page cache plugin helps.

But serving that HTML from the closes node rather than your origin server is what are after.
Cache everything does that but again the admin bar is a problem.
Railgun could be a solution (on paper) but $200/mo is too much for most folks here (me).

1 Like

I use Cache Everything on several of my Wordpress sites. The key is:

Don’t browse the site with your admin web browser. I admin the site with Safari. I use Firefox in Privacy, or Chrome in Incognito to view the site.

1 Like

I get by disabling the admin bar for sites i’m the only user, but some sites have many users logged in.
I guess i could disable the admin bar for everyone via functions.php and link to /wp-admin/ on a custom top bar.

If you expect to have users logged in, you likely don’t want to cache everything, there are too many cases where this will fail. Cache everything is really only suitable for mostly static sites in most situations.

1 Like

I am testing it. Wordpress sends these headers for logged in users:
cache-control: no-cache, must-revalidate, max-age=0

So these means:

  1. A logged in user can never generate cache, so nobody will see admin bars or “edit” links on posts they shouldn’t be seeing.
  2. A logged out will generate the html cache.
  3. When a logged in user visits a previously cached page he will HIT the logged out cache. Effectively ignoring the headers “cache-control: no-cache, must-revalidate, max-age=0”
    so he won’t see the admin bar or “edit” posts links.

I’m interested in your findings.

I don’t think that has anything to do with Cloudflare caching at the edge. Perhaps you misunderstood the issue. Folks want WP generated pages to be cached by CF - such that requests never hit WP but instead are served by CF. The problem is pages that must bypass CF’s cache - like wp-admin, ecommerce, etc.

I understand what they want but I think the desire comes from a fundamental misunderstanding of what should or should not be cached from a Wordpress site.

They are trying to shove a square peg through a round hole and then wondering why it is hard.

If they did have the “bypass on cookie” feature in the free version, and turned on Cache Everything; they would largely get the same results from my simpler free version. (cache standard, use origin cache) since Wordpress largely operates with cookies.

A user can always generate a completely static version of their front page and cache that if their landing page load times are too high.

Well, not really. You posted to a 2-month old thread so it’s sort of out of context. They wanted to cache WP pages except for wp-admin whereas you are talking about ecommerce.

I understand the overlap in outcome with your differing reason for doing so. Can you post examples from your website? A page that is cached by Cloudflare, and a page that is not? A lot of people will be interested.

I stumbled on this thread after going down the rabbithole trying to figure out what the ideal WP/CF setup was myself and reading conflicting things. I hate finding a thread explaining the same issues that leads to no resolution at the end. So in the interest of explaining this again:

WP is dynamic content, you don’t cache runtime created content.

Free tier optimal cache setup:

  1. Page Rule 1: your uploads directory as Cache Everything so all images are always cached
  2. Page Rule 2: Standard, Origin On is the most optimal cache technique for Wordpress using CF free tier.

If a user wishes, they can actually generate a static version of their wordpress site and serve that site via CF instead. They would be doing wp-admin on the dynamic backend version of the site.

It seems like people want the best of both worlds without picking a model.

Again you’re off topic for the original thread. The others want to cache html pages generated by wordpress for people not logged in.

This is a blanket statement and not always the case. Yes WP is dynamic. But in most cases people write pages/posts or use it as a cms - static content. Perfectly fine to cache on the edge.
PHP. CFML. ASP. etc… all dynamic runtimes. You wouldn’t cache any of their pages?

  1. Will what you describe cache html in Cloudflare?
  2. Can you post examples from your website? A lot of people will be interested to see your instructions working.

No one appreciates the condescension. I’m trying to not turn this into a pissing match regardless. You’re saying everyone is wrong, but this thread wasn’t even about your scenario of ecommerce. You can’t show us an example and you’re hiding your identity.

So truly make this a teachable moment for us. Does your method cache the wp-generated-html, on cloudlfare, for users not logged into wp? That was the original goal of this thread.

CF doesn’t cache certain extensions (pages/documents) regardless of origin cache control headers.

If I explain more of the basics of cacheing, I think you will perceive it as condescension. So I am trapped in a bit of a Catch-22. Talking with you has been largely non-constructive as you don’t have any feedback that makes my best solution better or any reason why it doesn’t work as the “best but not perfect” solution.

I would just suggest to anyone else who stumbles on this thread the way I did via searches and such to read what I said carefully and evaluate it since the official CF documentation on wordpress/woo would push you toward the pro tier by default when you can get great cacheing that is safe for dynamic content on the free tier.

Don’t mind the trolls!

Editing this post since the admins had to lock topic due to the toxicity of one user.

@Rubious I hope you read my posts and understand why the request is in itself not an expectation to have.

However, I will say this. You could test running multiple domains to the same wordpress with a plugin that allows for those domains to persist when entered from.

Then tell nginx to rewrite urls with cookies (like the worpress logged in cookie) to a seperate domain you have pointing to your site.

2 page rules:

  1. cache everything at primary.domain.mysite
  2. cache standard, use Origin headers, at redirect.domain.mysite (e.g.

@109guy I was the one who started this topic and I can confirm you’re misunderstanding what it was all about.

We want “Cache everything” on all pages, so it loads super fast. But we want it to only cache non-logged-in content, because when you’re logged in there is a WordPress Admin Bar at the top, and we don’t want non-admins to see that.

It’s nothing to do with /wp-admin/ or eCommerce.

Here’s hoping we can get this feature outside the $200 per month tier.


Thanks for the followup. And with that, I’m going to close this thread.