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 -
BUT NOW: 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.
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.
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
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.
A rule like this would work, with a couple caveats:
in place of example.com put your domain (the one you reach, if you have a redirect to www.example.com 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.
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.
Do select Bypass cache, which is the important bit.
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 *deadeasyapps.com/*, 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 Archive.org 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 Archive.org it is NEVER ON on any of our 300 sites.
that fiasco cost us over $163K and damn near ruined the company
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
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.