Comet Cache not caching pages with any s2Member shortcodes

Currently none of the pages on the site that utilize any shortcodes are getting cached for logged in users, including the homepage, and are instead displaying this message at the bottom in an html comment:

Comet Cache is NOT caching this page, because the s2Member plugin set the PHP constant COMET_CACHE_ALLOWED to a boolean-ish FALSE value at runtime. The s2Member plugin is serving content that must remain dynamic on this particular page, and therefore this page was intentionally not cached for a very good reason.

This is a very busy membership site, and this issue is causing the server to get hammered. I had to make a manual flat html copy of the homepage yesterday just so the client could make new posts, which is for obvious reasons sub-optimal. According to this bug report this issue was supposed to have been fixed with s2Member & s2Member Pro v160423:

We are using Comet Cache Pro 170220 and s2Member Pro v170722, with a child theme for Genesis 2.4.2. There are definitely some pages that are getting archived, so it wouldn’t appear to be a theme issue. I am a programmer and am comfortable implementing a manual fix if anyone has one. Any help is appreciated, thanks.


Actually, if you read the thread to which you linked, you will see that s2Member prevents caching where one of its “more dynamic shortcodes” is used. So what you are seeing is expected behavior.

Is there, perhaps, a way to place the shortcode on a page that isn’t so busy?

Thanks @KTS915. Is there a way to find out what constitutes a “more dynamic” shortcode? And a way to bypass that? The only reason to make a “no exceptions” anti-caching rule should be if the shortcode spits out user-specific code, such as a form pre-populated with a user’s info, which these do not. In fact, I just discovered that it’s not caching the homepage, even for non-logged in users, which makes no sense at all. The shortcode on that page is just an if statement that changes a link depending on whether or not the user is logged in:

[s2If is_user_logged_in()]<a href="/category/newsbud-daily-picks/">VIEW ALL</a> [/s2If] [s2If !is_user_logged_in()]<a href="/page/membership-options/">VIEW ALL</a> [/s2If]

If the plugin is able to cache pages for logged in users, this is exactly the kind of thing it should handle, shouldn’t it? Just one cached page if you are, and one if you aren’t?


That’s never going to work, I’m afraid. When you cache for logged-in users, it has to be per user. It can’t be just one cache for all logged-in users.

Which is fine, how do I make that happen? Because currently it’s not caching for either logged in or logged out users.


Only by not using such dynamic shortcodes. Otherwise, s2Member will render it impossible.

@KTS915, thanks. Quick question, are you a programmer?


@KTS915 - I just reread that thread and I realized you were the one who originally reported it. Please look at this section again though:

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.

It is saying that when s2Member encounters an s2 conditional it prevents caching of those pages, but that Comet Cache can cache those pages intelligently, so s2Member should allow the caching to happen. It should only prevent it is user-specific shortcodes are used, such as [s2Member-Profile /]. However, this isn’t happening.


Sorry, but that’s not what it’s saying. It’s saying that Comet Cache will cache when there are user-specific settings. A conditional that just checks whether someone is logged-in is, by definition, not user-specific.

@KTS915, I’m not trying to get in an argument here, but you are reading that wrong, and unfortunately you are the only one replying here. It very clearly says that s2Member will prevent the action, but Comet Cache can allow it because Comet Cache allows for user-specific content to be cached in an intelligent way. The author of that post may have been wrong in what he was saying, but that is what he said. I will try and open up a bug report. Thanks.


I’m not reading it wrong. You are just reading it out of context. You can see this clearly if you read what Jason wrote towrds the end of that thread. I highlight below the parts that are particularly relevant.

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-Profile /] shortcode to a page it cannot be cached, even if you tell Comet Cache to allow caching of logged-in users. That’s s2Member flagging dynamic content that it considers uncacheable.

In other words, what you are looking for is not currently something that is going to happen.

We aren’t adding [s2Member-Profile /] to a page. Do you have a list of which shortcodes are cachable, and which aren’t? Thanks.


No, I don’t. All I have to go on is the “more dynamic shortcodes” phrase that I have just quoted. That’s why I quoted it earlier in this thread.

All you can really do, I suspect, is a bit of trial and error. If you find a shortcode that does allow caching, then you can see if you might be able to modify it so as to achieve something more like you want.

You need to understand, though, that there is a good reason for s2Member’s behavior. It is caused by the way that WordPress validates each user, which involves nonces. s2Member (and Comet Cache, come to that) is trying hard not to mess up those nonces, which could cause huge security problems. This is why it is generally not possible to cache content for logged-in members at all, and why Comet Cache is set up to do this only user-by-user.

Let me offer some clarity here. The following quoted sentence above from the GitHub issue is causing the confusion:

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.

This is not saying that Comet Cache can cache pages that have s2Member shortcodes. I can see how you might be led to believe that based on the previous paragraph that was talking about s2Member shortcodes, however s2Member shortcodes (and conditionals—anything dynamic) simply cannot be cached (even by Comet Cache). They are not cache-compatible. If your home page uses an s2Member conditional, no matter how simple, Comet Cache won’t cache the page.

The point that was being made about Comet Cache being able to cache pages when s2Member is running is not referring to caching pages with shortcodes. It’s simply referring to caching other pages (that don’t have shortcodes or conditionals).

By default, s2Member defines the DONOTCACHEPAGE constant, which all WordPress caching plugins (including Comet Cache) obey to mean that the page should not be cached under any circumstances (even if the page doesn’t have any s2Member shortcodes or conditionals on it). With other caching plugins, no page will be cached when s2Member is active, even if the page is cache-compatible.

However, since s2Member and Comet Cache were developed by the same team, we allow Comet Cache to cache pages when s2Member is running, as long as those pages are deemed cache-compatible (i.e., as long as they don’t have any s2Member shortcodes or conditionals on them, which are inherently NOT cache-compatible).

@raamdev, thank you. I get what you are saying, although I still don’t understand the logic. When jaswrks said this:

What “user specific” content can be cached? And why would any user specific content be cacheable, but not a conditional?

And even moreso, why wouldn’t logged out users be cached, period? Currently nothing is getting cached, logged in or out, when there is a conditional on the page, and that seems like a bug for sure.


When a user is logged in, any pages on the front-end that they visit are “user-specific content”. Comet Cache can cache pages when users are logged in with the Logged-In User caching option enabled. Comet Cache maintains a separate cache for each user to ensure that content generated for one user does not get seen by another user (i.e., the content is cached “in an intelligent way”).

When s2Member + WP Super Cache (or any other caching plugin) are enabled, s2Member disables WP Super Cache everywhere, no matter what, no exceptions.

When s2Member + Comet Cache are enabled, s2Member allows Comet Cache to cache pages that don’t have s2Member shortcodes or conditionals. This includes both logged-in users (when Comet Cache Logged-In User caching is enabled) and non-logged in users.

I seem to be experiencing something similar. Even my static pages (like the home page) are not cached. The only thing “dynamic” I have on that page is a little snippet that allows the user to login:

[s2If is_user_logged_in()] Welcome [s2Get constant=“S2MEMBER_CURRENT_USER_DISPLAY_NAME” /] / My Account / Log out [/s2If] [s2If !is_user_logged_in()] Login Register [/s2If]

How can i cache anything on my site if Comet Cache is not caching the pages with a login code like that? Or am I doing this all wrong?

Carole, that is about as dynamic as you can get! You are saying to show certain content for those logged in, but to show something quite different for those who are not.

If Comet Cache cached that page, it could only cache one of those, and then you would have a major problem.

You should instead set up a redirect for those logged in (and not by using a shortcode) so that then you have two independent static pages.

Maybe I am not understanding correctly, but that code does not prevent content from being shown, just the “login” vs “logout” and “Welcome [name]”. No other content is protected. I obviously have some pages with more protected content on my site. After all, that is why I am using s2Member, but how can I have a login snippet on my pages if that would prevent any caching whatsoever?

Anything within your conditional is shown only to those who meet that condition. So of course it changes what is shown. That’s surely the point.

If you want to cache pages, you will need to remove the login form from them and instead have a dedicated login page.