@ittone We have recently released the new version 3.2.7 please try to install the same and check if you still get the same error?
@ittone Are you using a CDN? If so, which one?
Upon deactivation, we do delete the minification files. It is because, we can’t distinguish between temporary and permanent deactivation. Besides, if plugin is deactivated it means that there is some significant change is going to happen on the site. In that case the already cached files become obsolete, so fresh caching is needed. That is the the reason for file deletion.
The 404 errors can only happen when a CDN has old cached files which in turn refer to old minified js/css files. In that case upon deactivation, you also need to purge the cache in CDN
Thread Starter
ittone
(@ittone)
Hi Guys,
In answer to your question “Are you using a CDN? If so, which one?”
The answer is NO……But, the majority of visitors attempting to access pages which have been deleted (de-activated expired minify cached files) seem to be mainly visiting from that type of network.
Good example: google.com bots where the majority of these 404 errors originate from, closely followed by other BOTS….We have also seen many examples of human visitors presumably using their browser cache info to access….now…non existent cache.
So, we have no way of deleting cache files outside of our control.
As for not being able to distinguish between a temporary and permanent deactivation, how about upon installation/upgrade, a temporary minify reference file was created in the wp-optimize directory or for that matter, the cache directory. If a de-activation of minification was made the file being present prevents the deletion of the minify cache files.
Upon de-installation of the plugin, you could provide an option to retain or totally delete the minification files, stating the consequences of doing so if deleted.
OR
Just retain the minified cache files upon deletion of the plugin.
For users of your plugin, including ourselves who would at some point experiment with different minification plugins, say for several days would all see these 404 file not found errors and as us have been presented with thousands of these errors per day on a continuous basis until the remote servers cache expires. In many cases this is seven days, but we have seen one month and even three months attempted access to expired cache files.
Hope this helps, as it certainly would as a fix.
Thanks
Tony
Thread Starter
ittone
(@ittone)
One further note that I failed to answer.
I’m afraid I have to disagree with part of the following statement:
“Besides, if plugin is deactivated it means that there is some significant change is going to happen on the site. In that case the already cached files become obsolete.”
By any remote site attempting to access cached minified files (no matter from what server/workstation in the world) and those files have been deleted from the host server, then those files have NOT become obsolete UNTIL such time as the source server/host cache files have been purged.
As I stated in my previous reply, this could be anywhere between three days to three months as I have already proven during our initial investigations several months ago.
Today, we have NO minification 404 cache errors on any of our customer sites as,
1: We have not disabled the minification of JS and/or CSS files for four or more months.
2: All remote CDN, browser caches etc. have flushed their cache at some point during this time spell.
Thanks
Tony.
Data Centre Administrator.
Hi @ittone,
The minified assets such as js/css can only be requested/fetched because the html page being requested has references to those assets.
Is Static file headers option in cache section on or off?
When it is on all the HTML response has header Cache-Control: private, must-revalidate . So, theoretically, no client should cache the HTML page (which contains reference to minified assets). When you turn of Minify option, new HTML response will be served which as no reference to the old minified assets. 404 errors can’t be happen in this scenario.
If static file headers is off, in that case there is no cache-control or expires headers in the HTML response, so client shouldn’t cache the result.
Again, this is theoretical.
So, We need more information about the user agents (ex. google bot) and the HTTP protocol they use in order to further investigate and fix this. Thanks.
Thread Starter
ittone
(@ittone)
Hi Venkat,
We raised this issue in March of this year. Personally, we have a workaround and no longer disable WP-Optimize minification whilst performing maintenance tasks, so as already stated, these 404 errors no longer happen on our servers. However, as this issue has recently been reported by someone else on my initial thread which I raised in March, I have checked on my test server and sure enough the problems still exist when minification is enabled for a couple of days and then disabled.
During March, all minify 404 errors were re-directed to the respective homepages using 302 redirects.
Fortunately we have retained a portion of the Apache logfile and you are welcome to view it to see the information that you requested above. Please note that the logfile shows 302 instead of 404.
https://www.backtothemovies.com/wpo-minify.log
Also the static file headers ARE enabled, but are set to:
# HTML
ExpiresByType text/html “access plus 0 seconds”
Thanks
Tony
-
This reply was modified 3 years, 6 months ago by
ittone.
Hi Tony,
Thanks for the additional info. So even though the servers says, don’t cache HTML response,
# HTML
ExpiresByType text/html “access plus 0 seconds”
It seems some user agents doesn’t honor it which results in 404 errors for minified assets. We will add more headers to make sure the HTML is not cached.
You can expect this implementation in our October month’s release
Regards,
Venkat
Thread Starter
ittone
(@ittone)
Nice one Venkat.
Keep up the good work, in our opinion, on the fastest and best cache & minify WordPress plugin.
We don’t compare using speed test sites…….We use real world browser response figures.
WP-Optimize beat WP-Rocket in both cache and Minify in our tests a couple of years ago. Now that speaks for itself.
Tony.
Data Centre Administrator.
