Weird WordPress issue ONLY fixed by a COMPLETE PURGE of cache OR Development mode

We have a WordPress that has been running on a Centos server for 2 years, no issue
We use Wordfence security and Thrive themes, not much else.
We use Cloudflare APO
It is a Cloudflare Pro site
If we run in Cloudflare development mode, we don’t see the error.

We run the s2membership plugin and it is set to send each user to their own “Profile” page.
Worked fine till about a month ago - no changes to site, NO recent update to S2 plugin -
when user A logs into the site, they often see the profile screen of some OTHER user, sometimes even ADMIN! (either currently logged in or someone who was but left)

The only fix is do do a Cloudflare PURGE of everything or run in development mode ON Cloudflare. (running in maintenance mode on WP does NOT fix the issue)
We do NOT use a local cache plugin, only Cloudflare.

We have spent weeks turning off various plugin, even ALL plugins, but it still happens.

Hoping someone has an idea we haven’t thought of yet.

Sid B.

The only idea that comes to mind is that the different profile pages aren’t different URLs, but use some other method for the id of the user.

I’d need a better example, unfortunately.

I’m not sure what it uses, but since the error does not exist is running in Cloudflare development mode - which bypasses CF and the CF edge cache - I don’t see a local plugin being at fault. If it were the membership code was at fault the error would always be present, cached or not.

I appreciate your help though :slight_smile:

No need to explain, I know the issue is technically the Cloudflare caching layer, but it must be caused by some setup, because you are serving a non-cacheable page, with caching headers, to the user.

Cloudflare caches it, as it’s instructed to do so, and shows that to the next user that hits that colo.

I need some examples, a page, some headers, something.

1 Like

Live Page head section when running in development mode on CF:
Shows correct info, but I can’t load code here - due to the theme stuff, the head sections has about 58,000 characters - exceeds display length

You can’t “see” it because it’s a member only page


Share at least a screenshot of the headers you get back from the server when dev mode is on and when it is off.

Forgive my ignorance, but not sure how to do that.
In defense, I am not the tech guy - he is on vacation. I’m the support person trying to help freaked out users who want to know why they are seeing other peoples data.
I have been getting up every 2 hours for 2 days to reset development mode on.

Ok, lets proceed in steps.

First, let’s avoid this.

Do you have a specific path you are seeing this issue on?

Go here ( and let’s create a rule to bypass cache for the specific URL.

A rule like this would work, with a couple caveats:

  1. in place of put your domain (the one you reach, if you have a redirect to put the final domain).
    If you have both active (you should consider redirect one to the other, but outside of the scope now), create two rules, which is the easier path for now, one for each.
  2. In the URI Path case I selected equals, but might be better use a starts with or another alternative depending on the URL.
    You can share here the path(s) and I can help you decide.
  3. Do select Bypass cache, which is the important bit.

Now dev mode should no longer be needed.


Thank you for your patience

I did discover a page rule where they have a page rule set where (we have WP on subdomains having same issue)
set to
Cache Everything
and TTL for edge to 1 hour

But we have overall cache level set to “standard”
I wonder if the rule should be changed to “standard”?


Yeah, that’d be the main issue. Normally Cloudflare doesn’t cache HTML, that rule would make it so.
I’d personally just disable the rule and purge the cache, it should fix the main issue.
The rule applies to **, right?

It will of course slow the site down, but at least let you sleep.
APO should help and more rules can be added later.

ok, we will not EVER use APO
Because of just showing people any page they like, hackers attacked out site 2 years ago and CRASHED EVERYTHING.
We filed a law suite against them - still pending.
Since APO uses it is NEVER ON on any of our 300 sites.
that fiasco cost us over $163K and damn near ruined the company

You said you use it…

It’s not APO using, though. That’s always online mode, which is a separate setting.

Oops - I’m sorry. Tired. I think it was “Always Online” that uses Archive, so we turn that off.
It has been a long 3 days.
I won’t delete the page rule yet - there must be a reason it was set. He’s an ex NASA Network Engineer, so there must have been a reason.
I’ll just keep it set to standard and pray :slight_smile:

Disable it, while keeping as it was :slight_smile:
A rule for Standard makes no sense :slight_smile:

That’s just to reduce the load on the server, which means either the server is overloaded (so an upgrade might be in order) or WordPress isn’t optimised well (which is way more likely)…

Do remember to Purge Cache now :slight_smile:

1 Like

well in config, cache level is set to “standard” - recommended by Cloudflare

I definitely understand not using Bypass in that rule :slight_smile:

there are a couple of other more directed rules that do use bypass
and a couple I know where set because Cloudflare was causing issues with Thrive Themes and our page builder

Yeah, that’s a nice default for people who want to set and forget :slight_smile:

There are things one can do to improve things though. But not now for sure :slight_smile:

we use Cloudflare plugin for Wordpress?
I was told it turns Cache Everything on in the APO settings?

If true - unless page settings overrule it, Having Cache Everything active when using APO would be counter productive. I am surprised it has “Cache Everything” to optimize a WordPress site! As a CMS that is session based it would cause issues like we are seeing.

I don’t think Cloudflare is tuned very well for WordPress - we have constantly had issues over the last 2 years. That’s why we have 12 page rules.

Since I turned APO off in the plugin, we have had no Login issues. No cross-account displays. Just crappy speed.

We don;t use a local cache plugin, as we thought Cloudflare would handle it, but if APO is going to cause issues with 3,000 user accounts, we can’t afford it.

We will obviously have to find a local cache plugin that works since APO insists on caching the entire damn site on the edge as HTML and ignoring headers etc.