@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://www.ads-software.com/hosting/.)
