Tons of 404 errors for non-existing JS and CSS files

Hi MArtin, that is very weird. Once the plugin is installed, the files should all be there.

Could you check via FTP if the plugin directory /wp-content/plugins/easy-fancybox/ is actually there? And if so, the files that should be inside its subdirectories /js/ and /css/?

The subdirectory /fancybox/ does not exist anymore in the latest version so you should not have these files references in your page source code. Can you provide a link to your site so I can check?

Hi,

the version I have installed is 1.8.9 which seems to be the current version.

The website is: https://www.pro-taucher.de

The main directory of the plugin has the following directories/files:
css/
images/
inc/
js/
languages/
easy-fancybox.php
readme.txt

For example, I do not see a fancybox directory where some of the files mentioned above should be in. Hm…

Cheers,
Martin

Hi again, that is correct. The /fancybox/ directory should not be there anymore since it was removed in the latest version.

You may be seeing these access logs from crawlers that request resources based on an older version of your site. Looking at your current page source code, all seems fine and there are no files missing. The light box should be fine.

The access logs will pass once these crawlers update the source code they have in their cache.

Hi,

ok, I understand. I was wondering as there are so many 404 in just one month (November) and also many the months before.

Sorry that I rang a bell here.

Thanks again and cheers,
Martin

Can you see in the logs who is trying these non-existent files? Or where these requests are coming from?

I checked for today. There are some connects from Google Bot, but also “real” traffic. E.g.:

xxx.dip0.t-ipconnect.de – – [29/Nov/2018:00:43:21 +0100] “GET /wp-content/uploads/pro-taucher_site-logo.png HTTP/2.0” 200 22071 “https://www.pro-taucher.de/wp-content/plugins/easy-fancybox/fancybox/jquery.fancybox.min.css” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36”
xxx.dip0.t-ipconnect.de – – [29/Nov/2018:00:43:21 +0100] “GET /wp-content/plugins/sam-pro-free/js/sam.pro.layout.min.js?ver=1.0.0.10 HTTP/2.0” 200 620 “https://www.pro-taucher.de/wp-content/plugins/easy-fancybox/fancybox/jquery.fancybox.min.css” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36”
xxx.dip0.t-ipconnect.de – – [29/Nov/2018:00:43:21 +0100] “GET /wp-content/plugins/wp-gdpr-compliance/assets/vendor/micromodal/micromodal.min.js?ver=1543436779 HTTP/2.0” 200 2050 “https://www.pro-taucher.de/wp-content/plugins/easy-fancybox/fancybox/jquery.fancybox.min.css” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36”

I’m afraid there is nothing you can do about this. Even restoring an older plugin version (where this file still exists) would only change the access log response code value from 404 to a 200.

The plugin was changed to use the version number in the file name (and remove the request parameter version number, to allow proxy caching) which could mean that these requests are coming from proxy caches. I can only assume they will be updated at some point after which the new file names will be used, and the 404 log entries will disappear.

No worries, I won’t change anything. I don’t care a lot about the 404 errors, I just saw these in the stats. Hopefully no user experiences are harmed by proxy oder other caches.