Raam Dev

Many of the visual editor and page builder plugins that I’ve seen for WordPress have their own caching systems built-in that store pre-generated CSS/JS files either inside the cache directory or inside the uploads directory. That often causes problems when there’s another caching plugin enabled (it’s not a problem unique to Comet Cache).

Unfortunately this is something the page builder plugins would need to take into consideration. It’s possible they’re changing their own internal cache without hooking into actions that would normally cause the installed caching plugin to clear its entire cache. That might result in a cached page referencing a now-deleted CSS/JS file that the page builder plugin had cached, thereby causing visual elements on the page to look broken until the cache is manually cleared.

Comet Cache hooks into dozens of actions throughout WordPress Core to listen for various events that would warrant an automatic clearing of the cache, things like save_post and edit_post. It also hooks into various actions that fire when themes are changed, updated, etc. A plugin that creates its own cache should be firing one of these well-known hooks so that anything else (such as Comet Cache or another page caching plugin) that listens for those important events knows that it should also clear its cache.

Yes, the Comet Cache Client-side Caching is different from browser caching. The client-side caching controls whether or not WordPress disables browser caching for dynamic WordPress-generated pages which is the default in WordPress since WordPress sites are generally dynamic and for that reason it would usually be bad to have the browser cache anything generated by WordPress.

I would need to double-check the codebase (I’m on my phone at the moment) but I believe Comet Cache Simply disables the WordPress nocache_headers() function: https://codex.ww.wp.xz.cn/Function_Reference/nocache_headers

When those are disabled, whatever headers the web server sets are what get set. I’m fairly certain Comet Cache does not explicitly set any headers for browser caching at all.

1. Isn’t the whole point of the HTML compression more than just the CSS & JS files? It pretty much makes a mockery of what your plugin is trying to do!

Hmm, I’m not sure I understand your statement. The primary role of Comet Cache is a page caching plugin, which helps reduce the amount of PHP processing and WordPress database queries executed on each request, which thereby speeds up WordPress.

HTML Compression (and JS/CSS compression) are an entirely separate thing and many WordPress caching plugins don’t even provide such a feature. In fact there are separate plugins, like Autoptimize, that are geared specifically towards HTML, CSS, and JS compression / caching.

2. I’m pretty sure this could be done pretty easily with a htaccess rule using regex?

It could not. If you’d like to prove me wrong by providing such a snippet of .htaccess code, I’d be more than happy to take a closer look.

You still haven’t addressed how I can test this with a fresh install somewhere (given that it’s the GoogleBot that’s seeing the issue).

I have addressed it, here.

Frankly your attitude when it comes to a potential ranking issue for your customers is surprising. You don’t seem to be concerned at all!

I’m sorry if you feel that way. My job as a plugin developer is to provide and maintain a plugin that provides a specific set of features. My job is not to provide consultation services for any specific site or provide specific help for your specific set of requirements. That would require working with a developer who can provide that sort of service. The scope of our support for the Pro version can be found in our Support Policy.

You would need to set up a test site with Comet Cache running using the same options as you have on the live site (you can export/import options with Comet Cache Pro in Comet Cache → Plugin Options → Import/Export Options) and then have the search engine crawl that site.

I know this is very inconvenient, but there really is no other way to be diagnosing the issue.

The other thing you could do is just disable the HTML Compressor feature of Comet Cache (since that’s where the 404 links seem to be reported from) and see if that solves the problem. If it does, you could try using a different HTML compressor, like Autoptimize and then see if you have the same issue with that plugin.

@clocksaysnow @changeagent

I will answer all of your questions below.

Does your plugin collect personally identifiable information (that includes IP addresses)?

No. The free version of Comet Cache (available here on ww.wp.xz.cn) does not send any information outside of the site or collect information in any way.

The Pro version does send some basic environment information to WP Sharks about the server where Comet Cache Pro is installed to help plan for and improve future versions of Comet Cache (it does absolutely nothing with information about your visitors). All of the information collected by the Pro version about your hosting environment is stored anonymously with no identifying information (that includes no IP addresses).

In the Pro version you can disable this with a filter. Again, this only applies to the Pro version.

The free version of Comet Cache does not “phone home” in any way, as that’s not allowed as per the ww.wp.xz.cn plugin guidelines.

If so, what types of personally identifiable information does your plugin collect? For what purpose(s) does your plugin collect personally identifiable information?

For more information on what the Pro version collects, please see this article.

Does your plugin have a privacy policy that explains how you use my website visitors’ personally identifiable information?

Comet Cache Lite (the free version) and Comet Cache Pro do not collect any information whatsoever about the visitors to your site.

Do your plugin use cookies or collect various types of data-usage information?

No, Comet Cache does not use or store cookies.

Does it use Google Fonts?

No, Comet Cache does not use Google Fonts.

Does it track any personal data, like IP address, location, browser type etc.?

No, Comet Cache does not store or track any personal data.

Is there any other type of tracking happening?

Please see my reply to the first question at the top of this post.

Do you have a Privacy Shield certification (if you are outside the EU and in the US, I ask as I do not know where you are based)?

You can find our Privacy Policy here.

Do you have a Data Processing Agreement for EU customers?

No, we do not have a DPA at this time.

Do you have a supervisory authority (if you don’t have a presence in the EU?

No, we do not have a supervisory authority.

Does it ‘phone home’?

Please see my reply to the first question at the top of this post.

@the-moose The next thing that I would recommend is attempting to reproduce the issue in a clean WordPress environment to rule out conflicts with other plugin/theme code.

Hi @the-moose,

There’s no reason that Google should be indexing files in the wp-content/cache/ directory. The files in that directory need to remain web-accessible (especially the HTML Compressor files, which get linked to on various pages of your site by Comet Cache when you have the HTML Compressor enabled), but search engines should not be indexing anything there.

The files in the wp-content/cache/ directory frequently change, get deleted, overwritten, etc., as the cache is regenerated, which happens regularly and at various times. The filenames and directory names in the cache directory will also change whenever this happens, so it’s not unusual for a link to a file in the cache directory to suddenly return a 404. Whenever a cache file is regenerated and the name changed, Comet Cache automatically starts using the new filename so that a 404 is never returned for a resource that is being used on a page.

It sounds like Google indexed files in the cache directory and then reported that those files were returning a 404 at a future date—this is entirely normal for files in that directory.

I recommend adding a line to your robots.txt file that excludes search engines from indexing everything in the wp-content/cache/ directory. There’s an article here that explains how you can update your robots.txt file:
https://kinsta.com/blog/wordpress-robots-txt/

• This reply was modified 8 years ago by Raam Dev.