Add support for Comet Cache Pro logged-in user caching #888
referenced this issue
Feb 23, 2016
@jaswsinc In wpsharks/comet-cache#676 (comment) you write...
Can you elaborate on what "full compatibility" means? I was just testing the v160225-RC that includes your work to improve compatibility with Comet Cache, however it's clear to me that some pages are not going to be cached by Comet Cache due to the fact that the page contains a Pro-Form or other dynamic s2Member content.
The article on the s2Member site that @KTS915 linked to in the other GitHub issue doesn't seem to be very clear on what compatibility means either:
Would you mind clarifying what we can expect from from s2Member's compatibility with Comet Cache? The fact that this isn't clear to me is making testing this fix in the RC rather difficult (I'm not entirely sure what should and what should not be working).
s2Member will prevent caching on user-specific and/or dynamic content (e.g., Posts/Pages that contain an s2Member shortcode or conditional tag, the MOP and LWP, etc) whenever a user is logged in. This is an additional precaution on the part of s2Member to ensure that dynamic content it generates is never cached for any specific user and then displayed to another from the cache.
However, whenever Comet Cache (and ZenCache in the past) are running with user-specific caching enabled, s2Member can allow this to occur, because our plugins do in fact allow for user-specific content to be cached in an intelligent way. For this reason, there must be conditionals in s2Member that will look for the presence of these user-cache-compatible plugins like Comet Cache and ZenCache. If they are running and configured to allow for a user-specific cache, we allow those pages to be cached as one would expect them to be.
So the s2Member Login Welcome Page should get cached by Comet Cache when Logged-In User caching is enabled? If so, that does not appear to be happening with Comet Cache Pro v160223.1 + s2Member Pro v160225-RC:
OK. So sorry. The explanation that I gave for this before was not entirely accurate. Let me try this once more now I've reviewed the codebase again.
There are a few subtle alterations in s2Member when it comes to the LWP and MOP. However, the real issue between s2Member and Comet Cache (i.e., the reason for considerations to be made in both plugins), is because s2Member will prevent the caching of logged-in users. Period.
In other words, s2Member has built-in routines that will prevent any caching plugin from caching pages for logged-in users. This was in an effort to avoid caching plugin conflicts. Generally speaking, that's still a good idea in my view.
However, when s2Member can detect that Comet Cache or ZenCache are running, it allows those particular plugins to cache pages for logged-in users according to their configuration; i.e., it won't stand in their way. So that's the issue that was resolved here.
As for the MOP and LWP. Those pages can be cached for logged-in users like any other, now that s2Member has been updated for compatibility with Comet Cache. However, if you introduce some of s2Member's more dynamic shortcodes on a page, those will still prevent caching, no exceptions.
So for instance, if you add the
s2Member & s2Member Pro v160423 have been released and they include changes from this GitHub Issue. See the v160423 announcement for further details.
This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one. Thanks! :-)