Issue 7.6.2 update broke my server caching
7.6.2 completely broke my server level caching, causing my server to start throwing 502 and 526 errors and slowing the site. It is a very busy site and we basically rely on caching to serve up pages (another issue altogether). Right after I installed the update we noticed a large number of slow responses (server cache was being reset constantly) and we started hitting our memory limits as well. This seems to be the result of the Set-Cookie header that the plugin is setting which causes NGINX to not cache responses.
Can you address this? I have had to disable WP Discuz becasue of this and our readers are missing the features!
Please use the latest version (V7.6.3) of the wpDiscuz plugin. Once the plugin is updated, delete all kinds of caches and check again.
Let us know if you still see the issue.
I am still facing this issue even after 6.3 and deleting all my caches. It's exactly as the OP said where the cookies are invalidating the caching.
I posted some fairly specific information about the cause of this issue and now another user has commented they have the same issue. Your caching security fix broke server level caching.
The site I have this running on gets between 2.5M and 3M pageviews a month and this problem renders the server unusable. Constant misses of the server cache cause all of the viewers to hit the main server - not the edge caching servers - which brings our site to a halt.
So until you can tell me that your team has verified that the problem exists and that the devs had fixed and verified the fix, WPDiscuz stays deactivated on my server.
I'm not going to do your testing for you on a site that is this busy...
NO RESPONSE IN TWO WEEKS???
What is going on here?
This is a huge problem for any server that relies on caching because your 7.6.2 update BROKE NGINX caching and you guys are just not responding. I get that this could be a complex issue to deal with as the reason you broke caching was to resolve a security bug. I understand the development process, really I do. But you have to give me something to work with here.
I've explained why I can't just turn the plugins back on and "try" and see if 7.6.3 works (and you even have another user who says they have the same issue and 7.6.3 did not help).
PLEASE - Look at the screen captures I sent, it illustrates the issue, shows you the cookie name that is causing NGINX to break. PLEASE elevate this issue to your devs and at least let me know that you're working on it.
Or let me know that you're not going to look at it and I can remove your software from my server and let our readers know that the features they know and love are gone forever.
Either way, please don't ignore the issue.
Thank you for the update.
I did try the new 7.6.4 plugin but the set-cookie was still present in the header. Hopefully this will be fixed in 7.6.5?
The relevant info on NGINX caching is here:
How Does NGINX Determine Whether or Not to Cache Something?
NGINX caches a response only if the origin server includes either the
Expiresheader with a date and time in the future, or the
Cache-Controlheader with the
max-agedirective set to a non‑zero value.
By default, NGINX respects other directives in the
Cache-Controlheader: it does not cache responses when the header includes the
No-Storedirective. It also doesn’t cache responses with the
Set-Cookieheader. Further, it only caches responses to
HEADrequests. You can override these defaults as described in the answers below.
NGINX does not cache responses if
proxy_bufferingis set to
off. It is
While there are ways to make this work, it would require modification to all NGINX servers with WPDiscuz installed - that seems unlikely as a solution.
I noted increased PHP response time and cache misses - but I also flushed ALL of my caches, server, Cloudflare and WPDiscuz. So some slowness and misses were expected.
Unfortunately, I will have to disable WPDiscuz again until the set-cookie parameter can be removed from the header or an option to turn that function off is added. Hopefully that will be coming soon.