Requests that initiate a session are considered private, hence the no-cache header, as well as a unique session cookie. It’s not safe to force-cache such requests, and there’s really no point in doing so, since the cache will (or should, rather) be unique for each user anyway, so there’s very minimal performance benefit.
Doing session_start() on init/template_redirect/etc. is bad programming practice and in general it’s best to avoid plugins doing this. If you need to use sessions, the session must be initiated from a user action, such as when a user adds a product to cart in WooCommerce, only then they stop being anonymous and by-pass caches, etc.
Hope that helps!
Thanks for your reply.
WooCommerce doesn’t use PHP session, it stores sessions in the DB, so it might not be related and a good example of how to avoid in this case.
I understand your point and it makes sense. The problem is that the plugin I’m using uses a shortcode to let users login/logout and edit profile. They process the requests on “template_redirect”, hence the session_start() is used. It affects all pages and prevent them from caching by Surge.
I just wonder why WP Super Cache work well in this situation. I have to switch to it temporarily to deal with this issue.
Woo is actually a great example of how to avoid it, regardless of their session storage mechanism, which happens to be a custom implementation with the database layer. WordPress core also has user sessions (for wp_users) that don’t use PHP’s session implementation.
The ideas is still the same: create a unique user session (cookie) when they perform a certain action — add a product to cart, or login. So until the user has made that action, no unique cookie is issued, they’re anonymous, and that’s where caching works best.
In your case, the membership plugin seems to be creating a unique session on every page view (at template_redirect), regardless of whether the user is even logged in or is a member on the site, or is viewing a login page/shortcode. This creates a unique user session for everyone, and that’s the problem.
Not sure what your configuration for WP Super Cache is, but it sounds like you’re anonymizing requests (forcefully stripping cookies, etc.) and then using their exclude list to exclude the specific membership pages from ever being cached. If that’s what you’re doing then yeah, sounds like a good workaround for a badly written membership plugin. Unfortunately Surge might not have that option for you.
Hope that helps.
Thanks for your reply. That’s very informative and helpful. I learn a lot from that.
I think this topic can be marked as resolved.
