QUICK_CACHE_ALLOWED set to a boolean-ish FALSE value

[raamdev]

For some reason, s2Member is setting the QUICK_CACHE_ALLOWED constant to a FALSE value when loading protected pages.

If I'm running Quick Cache with Logged-In User caching enabled (Dashboard → Quick Cache → Plugin Options → Logged-In Users set to "Yes, and maintain a separate cache") and one of my s2Member users visits a protected page, the following appears in the HTML notes:

Is there actually a good reason or is this a bug?

Steps to reproduce

1. Install Quick Cache Pro (v140104 simply shows nothing in the HTML notes, while v140520-RC shows the message in the screenshot above)
2. Enable Logged-In User caching (Dashboard → Quick Cache → Plugin Options → Logged-In Users set to "Yes, and maintain a separate cache")
3. Install s2Member Pro (v140520) and restrict a post on your site to Level 1
4. Create a new user with Level 1 access
5. Login to the site with user created in previous step
6. Visit protected post and "view source"

---

Originally reported at wpsharks/comet-cache#174.

[jaswrks]

Thanks! It's the intended functionality. However, now that QC Pro allows for user caching I think there is room for improvement here in s2Member also. I'm not seeing any reason why s2Member could not allow protected pages to be cached for logged-in users.

I'm going to review this carefully before a change is made, but for now I agree with you. Looks like we'll need a new argument to this method in s2Member.

[jaswrks]

Hmm... I see that we may need to distinguish Quick Cache from other WP caching plugins too, before we allow this; since not all caching plugins would be compatible with a user-specific cache generation.

[jaswrks]

Moving this to the "Future Release" milestone.

[jaswrks]

Moving this to the "Next Release" milestone.

[jaswrks]

This was resolved in the release of s2Member v140614
https://github.com/websharks/s2member/releases/tag/140614

[KTS915]

This is great! Thanks very much!