Hi,
Hi!
I have Comet Cache Pro.
I am experiencing a problem with logged-in users. As soon as a user logs-in, Comet Cache stops serving compressed CSS, HTML, and Javascript files.
I tried to debug this for a full afternoon and cannot figure it out. I have switched ON all options under Logged-In Users (to serve seperate cache files for logged-in users, because this is a member site).
Can you help please? I am at my wits end…
Thank you!
Martin Perreault
/edit: removed caps
I have switched ON all options under LOGGED-IN OPTIONS
Please don’t use all caps. It comes across as shouting. And do you mean Logged-In Users? At the bottom of that section is an option asking Enable HTML Compression for Logged-In Users? Have you turned that on and hit Save All Changes at the bottom of the page?
But it really isn’t a good idea to do that, which is why it isn’t recommended. You will probably make the pages much slower to load.
Thanks for the reply, and sorry for the caps.
Yes I meant Logged-In Users tab., I switched ON all options because my site is a member site, and every description says to keep those ON if it is a member site. Therefore, I’m assuming that Comet Cache should combine and compress all CSS files and JS files (when I switch ON the compression of those functions under HTML Compression Tab, which I did. And yes I clicked Save All Changes button at the bottom. But still, the CSS and JS is not being combined nor compressed when a user is logged-in. It is only combined and compressed when the user is not logged in…
I don’t understand why.
Then it sounds like you have a conflict somewhere.
But, even if you do manage to get it working, I wonder if you understand what will happen. In fact, the cache for each logged-in user will last a maximum of 24 hours (and maybe just 12 hours) because it is limited by the life of a WordPress nonce. So if a member logs in every day to the same pages, s/he won’t get the benefit of a cache. On the contrary, it will have to be generated anew each day.
Now the process to create a cache is not usually too intensive, but it does add time to each page load. When you add in compression of CSS, JavaScript, and HTML, though – all of which has to be done before caching – you are adding quite a lot of work and page loading times for each page on first view will go up considerably. This is why I said that turning this on will likely make your site slower.
Caching for logged-out users doesn’t have these problems because:
I understand what you’re saying, however, since this is a member zone, users are moving back and forth between pages. So the cached combined css and js does have a positive impact on speed.
In Comet Cache, there is an option to force caching even when a Nonce is present:
Cache Pages Containing Nonce Values in Markup?
This should almost always be set to Yes. WordPress injects Nonces (numbers used once) into the markup on any given page that a logged-in user lands on. These Nonce values are generally used to improve security when actions are taken by a user; e.g., posting a form or clicking a link that performs an action. If you set this to No, any page containing an Nonce will bypass the cache and be served dynamically (a performance hit). Even the Admin Bar in WordPress injects Nonce values. That’s reason enough to leave this at the default value of Yes; i.e., so Nonce values in the markup don’t result in a cache bypass. In short, don’t set this to No unless you know what you’re doing.
I have set to: “YES, For Logged In Users, Intelligently cache pages containing Nonce Values.”
However, JS and CSS are still not combined and compressed when a user is logged-in.
I also tried installing Come Cache on a virgin wordpress site, with no additional plugins, and the problem persists. When a user is logged-in, the same issue is present.
I am wondering if this is a bug?
Where can I report bugs?
Yes, that’s right. It’s really important to use that option. But everything I said still holds true.
I have been there and done it. If you do get it working, you should time how long it takes to generate each page individually for each user. (Query Monitor makes that easy to do.) You might be surprised.
You aren’t even close to identifying it as a bug yet. I said earlier that it sounded like a conflict. Until you have ruled that out, you can’t even begin to think of it as a possible bug.
You aren’t even close to identifying it as a bug yet. I said earlier that it sounded like a conflict. Until you have ruled that out, you can’t even begin to think of it as a possible bug.
I did install it on a fresh wordpress install, and the problem persists.
What else do you suggest I do to find out if there is a conflict?
OK, that’s more like it. Bugs should be posted here: https://github.com/websharks/comet-cache/issues