WP Super Cache and S2Member Pro

Hi,

I’ve tried searching the site for an answer on this, but can’t seem to find anything.

I was reading somewhere that WP Super Cache is automatically set not to cache any protected member content. Is that true?

If so, is it even possible to cache protected content?

For some reason, the only page that my WP Super Cache will cache is the index of the site (which has S2Member protection turned off). It won’t, for some reason, cache other site pages that also have S2Member protection turned off though.

I have HTTPS, WP Super Cache, a WooThemes theme, and S2Member Pro installed.

Any help would be greatly appreciated!

Thanks,
Frank

• This topic was modified 4 years, 1 month ago by  Frank.
• This topic was modified 4 years, 1 month ago by  Frank.
• This topic was modified 4 years, 1 month ago by  Frank.
• This topic was modified 4 years, 1 month ago by  Eduan. Reason: Moved to customer support forums

Hi Frank,

I was reading somewhere that WP Super Cache is automatically set not to cache any protected member content. Is that true?

I believe you might have heard that about Quick Cache, which is created by WebSharks, Inc. (the creators of s2Member®) and generally works the best with s2Member.

I would recommend switching to Quick Cache to work with s2Member.

Hi Bruce,

That sounds about right.

Will I be able to cache protected areas of the site with Quick Cache though?

Thanks!

Frank

• This reply was modified 4 years, 1 month ago by  Frank.

Forgive my ignorance on this, but my thinking is that if a membership website (with lots of content) has a bunch of members who are logged in all at once, then caching would be useful for increasing performance (and decreasing the load on the server/database).

I just installed Quick Cache, so if you could provide recommended settings to get protected content cached (but still protected), it would be much appreciated!

Thanks again,
Frank

Hi Frank,

You’ll want to play around with the features a bit, but I would recommend turning caching on for Logged In Users (assuming you don’t have something like a sidebar that shows user data) and turning on Client-Side caching. You will then want to make sure you have stopped caching on your Login Welcome Page, Membership Options Page, and any other page that you are running dynamically-created content.

Thanks, Bruce.

Bummer, I do have a sidebar that shows the user’s name, and a link to modify their profile.

Hi Frank,

If you have dynamically-created content in pages, such as that sidebar, caching is not possible in those instances because that sidebar would not show up, or may even show up differently than it should.

Perhaps you could create a different template without the sidebar for posts and pages and not cache pages that would have this dynamic content.

Hi Bruce,

Thanks!

Yea, perhaps I’ll just remove that login/account info widget from the sidebar and make a separate page for account info then (and just exclude that page from caching as you suggest).

I would just add that page I want to exclude to the No-Cache URI Patterns Box in Quick Cache, correct?

http://www.examplesite.com/members/account-info -> put in /members/account-info in the No-Cache URI Patterns box?

Also, what if I use s2 conditional short codes throughout some of the logged-in content? Will caching mess that up as well? For example, I use s2 conditional short codes to display certain messages to certain levels of members, while hiding that message from other levels of members.

Thanks a bunch,
Frank

Hi Frank,

I would just add that page I want to exclude to the No-Cache URI Patterns Box in Quick Cache, correct?

http://www.examplesite.com/members/account-info -> put in /members/account-info in the No-Cache URI Patterns box?

Yes that’s correct. You would most likely want to just put /members/ into the URL Patterns, however, because anything under /members/ shouldn’t be cached.

Also, what if I use s2 conditional short codes throughout some of the logged-in content? Will caching mess that up as well? For example, I use s2 conditional short codes to display certain messages to certain levels of members, while hiding that message from other levels of members.

This also would need to have caching disabled as well, because caching creates a non-dynamic copy of the page to show users, so ALL users would see the same thing.

OK, that’s what I figured. Sounds like I’m not going to bother with caching at all then for now.

I wouldn’t want to include /members/ because that includes the very content I want to cache – static content (for the most part) that all members should have access to.

Is it not normal then to setup caching for the content behind the login wall? Seems like I’m outside the norm with what I want to do. What about membership sites that have a ton of protected static content, and a ton of active visitors bouncing around between that content? Would caching make sense for them?

I guess I’m just trying to understand why caching is turned off by default for logged in users, among other things.

Hi Frank,

Generally dynamic content is only created when a user is logged in (for example, Sidebar Info, and Messages, etc.) so disabling caching for logged-in users makes sense because it leaves the least amount of room for error.

However, if you did have a lot of static content that did not change based on users and did not have other dynamic content within these pages you could structure your site to separate this content from dynamic content and cache pages in the static divider.

Some themes do support features such as this, and if your theme were to grab data through an iFrame, or through AJAX you could cache all pages except those that are providing dynamic content through PHP.

Thanks a ton, Bruce. Very helpful advice.

I think in my case, it would simply be a matter of removing the account info widget (and relocating the info to a non-cached page), and removing the s2 conditional short codes (and figuring out a static way to accomplish what I used the short codes to accomplish).

Hi Frank,

Keep in mind that just caching pages for not-logged-in members can significantly increase your server’s speed. Many times search engines and just general browsing can slow down your site, and just enabling Quick Cache will speed up your site in the meantime.

Makes sense. The only reason I said I would ignore it for now is because most of my content isn’t even accessible to not-logged-in members, and there’s really only one page that non-logged-in members would be accessing (for now). Once I add more public static content, I’ll definitely cache all that stuff.

Sounds good.