Raam Dev

@ibiza69 Thank you for the review. 🙂

Note that the problem you’re describing will occur with all WordPress caching plugins, not just Comet Cache. Also note that most social share buttons and plugins use JavaScript to stay updated and JavaScript-enabled social share counters will not be affected by Comet Cache (or any other page caching plugin)—they will work as expected and the counts will be updated automatically without clearing the cache.

It sounds to me like you’re using a social share button or plugin that is incompatible with WordPress caching plugins.

@mpek

Does that mean that these files:

.htaccess
cc-advanced-cache

should not be deleted?

Yes, that’s correct. Those files should be left alone. If you do delete them, Comet Cache will automatically recreate them when you deactivate and reactivate Comet Cache (or if you click the “Restore Default Options” button inside the Comet Cache options).

@infolegal writes…

I assume I can safely delete the old tmp directory, right?

Yes, any -tmp directories in the cache directory can safely be deleted, however keep in mind that Comet Cache creates those directories as part of its normal operations, e.g., when clearing cache files from a directory the directory is renamed to a -tmp directory and then the files are deleted from that directory. Once the files are deleted, the -tmp directory is also deleted. (It’s done this way so that if a visit to the site generates a cache file at the same time that Comet Cache is clearing cache files, the two operations don’t conflict with each other.)

So, while it’s safe to delete -tmp directories as long as you’re sure they are old and have been around awhile, I wouldn’t recommend setting up a script or something that automatically deletes any -tmp directories from the cache directory, as that would interfere with the normal operation of Comet Cache.

in each directory there are two folders, one for http and one for https. Why is that? My site runs on https only (a redirect is in place to handle older http indexed pages and load them on https)

If your redirect is happening at the PHP (e.g., WordPress) level, then Comet Cache will see the http URL before it gets redirected and may create a cache file. So, all https enforcement should happen at the web server level, before the request ever hits PHP/WordPress. If you’re using Apache, you can do this by adding some rules to your .htaccess file. This ensures that even if an automated crawler (e.g., a search engine crawler) tries accessing URLs on your site without https, the web server redirects the request to https and then Comet Cache caches the page.

Related to this, I should mention that we also have a new Apache Optimizations option coming in the next release of the Pro version that lets you “Enforce Exact Hostname”; see this GitHub issue for details: https://github.com/websharks/comet-cache/issues/101

Regarding enforcing SSL: Here’s what I personally use in the .htaccess on my personal site:

# BEGIN SSL Enforcer
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# END SSL Enforcer

However, you’re running LiteSpeed and not Apache, so I’m not entirely sure if that will work for you. You might want to check with your hosting company.

My site is hosted on a cloud server (shared environement) CloudLinux

That is almost certainly the cause for the issues you’re having with Comet Cache being unable to delete files properly. Cloud-based hosting services often use distributed or network-based filesystems that don’t play well with file-locking or heavy writes/rewrites. I suggest working with your hosting company to see if you can resolve the issue or trying a different hosting platform. (See https://ww.wp.xz.cn/hosting/.)

@julius-e writes…

I take it that even with the fragment, these pages benefit from caching?

Yes, absolutely! The # fragments don’t even make it to the server, so Comet Cache treats the URL as if it didn’t contain those fragments and caches the page as expected. (If you were using query strings, e.g., ?WJ3JuNKP9hE, you’d need to enable GET Request caching to have Comet Cache cache those pages and each fragment would be cached separately. In your case you’re using # fragments, so Comet Cache just creates a single cache file for the page and serves it as expected.)

I activated client side caching as I am the only one who logs in/updates the site, but Gmetrix actually saw an increase in load times.

Hmm, it’s odd that you would see an increase. If you see a definite, consistent cause-and-effect (enable -> test result slow, disable -> test result fast) my only guess would be that allowing Client-Side Caching is somehow having an adverse side-effect in combination with your server configuration (which itself would be odd, but it’s all I can think of).

However, if you haven’t already, I do highly recommend enabling Browser Caching (which is different than Client-Side Caching; see the note about this in the Client-Side Cache section of Comet Cache). Browser Caching generally adds a considerable speed increase. In Comet Cache Pro you can enable this via the Apache Optimizations section and Comet Cache will automatically insert (and automatically remove if you disable the feature or disable Comet Cache) the necessary rules in your .htaccess file to enable Browser Caching. But if you’re using the free version of Comet Cache, you can simply edit the file yourself and add the following to the top:

# Enable browser caching.
FileETag mtime size

<IfModule expires_module>
  ExpiresActive on
  ExpiresDefault "access plus 1 week"
</IfModule>

Many thanks for your detailed replies, leaving a well deserved 5 star rating

Woohoo! Thanks so much! 😀

@julius-e “The fragment identifier functions differently than the rest of the URI: namely, its processing is exclusively client-side with no participation from the web server” (Wikipedia: Fragment identifier).

That means that the server never actually sees the #.WJ3JuNKP9hE portion of that URL and since Comet Cache is a server-side page-caching plugin (it uses PHP, a server-side language, to capture the output of PHP and serve static HTML versions of the page to improve performance), there’s no way for Comet Cache to see that fragment identifier and take it into consideration when caching a page.

So that means Comet Cache would see these three URLs as the same URL (even though their fragment identifier might be different, or absent) and will create and serve a single cache file:

mysite.com/category/my-article-url/
mysite.com/category/my-article-url/#.WJ3JuNKP9hE
mysite.com/category/my-article-url/#.Ju9EwPKf3Sj

If you need to cache those three pages separately, you should see if you can use query strings instead of a fragment identifier, e.g., /my-article-url/?WJ3JuNKP9hE. You could then enable GET Request caching in Comet Cache (Comet Cache → Plugin Options → GET Requests) and Comet Cache would cache each variation of the URL as separate and unique pages, each one getting its own cache file.

I should add that a great site for checking if GZIP Compression is enabled is https://checkgzipcompression.com/

I just checked your site, and it looks like GZIP Compression is enabled:
https://checkgzipcompression.com/?url=https%3A%2F%2Fwww.lornakirkbyphotography.com.au%2F

@infolegal I suggest enabling PHP debugging (see https://codex.ww.wp.xz.cn/Debugging_in_WordPress) to see if you’re getting any PHP errors when you try to clear the cache.

It sounds to me like the Comet Cache might not have permission to delete the cache files or that your server is otherwise preventing Comet Cache from deleting those cache files.

@stippie Thanks so much for the 5-star review! I’m so happy that you’re enjoying the plugin. We’ve put a lot of effort into compatibility with other plugins, including WooCommerce, so I’m thrilled that you’re finding that useful.

If you have any trouble with the Pro version that we might be able to help with, don’t hesitate to open a support ticket. 🙂