W3TC: non-existent js and css in cache/minify/ throw errors

Seems to me it might be linked in some page cache that won’t get cleared for some reason. When removing and installing the plugin again, did you also remove the cache directory entirely? And the w3tc-config directory and advanced-cache.php, db.php and object-cache.php files?

Thanks for your reply.
Before I forget it again, there is a syntax error reported in security headers section of browser caching:

Error parsing header X-XSS-Protection: 1; mode=block, 1; mode=block: expected semicolon at character position 14. The default protections will be applied.

Now back to your questions.
Yes, upon the last removal we did all of that. Upon interim removals (during testing) likely not.

I tested this a bit more now on the weekend: w3tc seems to create “default” cache resources even if minify disabled? Look:

GET …/wp-content/cache/minify/dd14f.default.include.b88444.css 404 ()
GET …/wp-content/cache/minify/dd14f.default.include-body.613814.js 404 ()
GET …/wp-content/cache/minify/dd14f.default.include-footer.3a2d34.js 404 ()

Could that have caused it?
Either way, does anyone have an idea how to delete references to non-existent files when you can’t easily find where they get referenced?

They are not in the db, that we know. I am confident they are inflicted by one wrong setting in browser cache?
However, tried both, Prevent caching of objects after settings change, ticked and unticked.
Minify is disabled throughout. During earlier testing of course it was on Manual mode. Does that maybe not get entirely cleared when you deactivate minification afterwards?

There also is a database table for We Total Cache called {prefix}_minify (if I’m correct). Did you delete the table as well? There might be a reference there.

That may be in some installation yes, it is not in ours though, no. Earlier I meant I searched the entire db, 100% certain, the files are not referenced in the db. Nor in htaccess.
As cache files won’t get programmatically hardcoded into php files, I am wondering where else they may be called from?

Also wondering, why w3tc newly creates those “default” cache files despite that minify is disabled?
That part certainly shouldn’t be, right?

Okay I have found WHERE it gets injected, I have not found how to stop that though as w3tc does not list them under browser cache where the security headers get entered.

Here’s where w3tc injects them:
x-powered-by:W3 Total Cache/0.9.7
pragma:public
link:</wp-content/cache/minify/c9f75.js>; rel=preload; as=script
link:</wp-content/cache/minify/8cba1.js>; rel=preload; as=script
link:</wp-content/cache/minify/69faf.js>; rel=preload; as=script
link:</wp-content/cache/minify/82053.js>; rel=preload; as=script
link:</wp-content/cache/minify/1c235.css>; rel=preload; as=style

found thanks to https://tools.keycdn.com/curl

I must be blind: I cannot see that been set anywhere in w3tc, so they must get auto-generated in the backend?
Why does w3tc do that when minify is OFF?
Anyone can shed some light?

In the meantime I found out:

w3tc has some issues with browser cache settings, and this is what generates the non-existent js and css links, as well as more issues:

2) When we tick “Prevent caching of objects after settings change” then any new settings should become effective, because caching is prevented via query string (and “Remove query strings from static resources” is UNticked of course)

The don’t become effective though: I had added some CSP directives to script-src and others, and just now I see WHY the console errors still show up: despite refreshing, browser restart, cache clearing, and what not, the browsers still pick up the old cache without those additions.

So seemingly “Save Settings &Purge Caches” is not reliable?

Worse, with these settings pages don’t display correctly, eg background images show up in wrong places.

3) When we UNtick “Prevent caching of objects after settings change” (and “Remove query strings from static resources” is UNticked of course) then pages display correctly again, BUT the caches still won’t clear: pages still have the old CSP directives.

Has anyone tested this deep into w3tc ongoings?

We cannot reproduce this issue so we would like to debug your system to help out. Could you go to Performance => Support and report the issue, linking this forum topic in your message, so we can contact you about the details?

Hey Gido are you a user too? And so friendly helping others? Impressed, thank you!
Doesn’t look here you work for Frederick?

Thanks again man! Okay I will. Hey I found another (may I say quietly? bug?):

w3tc, current version, seems to replicate into “frame-ancestors” what it finds in “frame-src”, can you reproduce this?

So: I delete “frame-ancestors” directives, enter correct one, reload page (browser cache), and again populated with same as frame-src – which frankly is wrong, they aren’t the same ??

Gets more weird though: Next please Export your settings, check the file with notepad++, and you see it DID overwrite it.

So now you refresh browser settings once more, cause you can’t believe it, and what do you see?

Again/still “frame-ancestors” is wrongly populated with “frame-src” directives.

Now that’s weird, huh?

I contacted Frederick a while ago and became WordPress Forum contact person. So I check the forum for bugs and help people as far as I can, asking for help when I don’t know the answer. My name will be added in the next release ??

I need the contents of your wp-content/w3tc-config/master.php file to be able to replicate your issues. Could you share them please?

Great, you are a huge benefit to wordpress forum, thank you ??

Hey look, I can now actually summarize my suggestions for Frederick and you, what to implement (may I say?) asap? lol ??
Sorry that it took me a few posts here before my head cleared.
So, two suggestions please:

1) There must be a way to NOT “overrule” a user’s own security headers (incl CSP), currently w3tc does, and I did read Frederick’s reasoning but (may I say so?) don’t agree on that point, no.
Can you ask him to cache AFTER the functions.php has been executed?
Reason: Most users (if they have an idea) will use functions.php for it (it’s simplest, quickest). But currently w3tc completely ignores one’s settings (= cannot cache that, he says).
Well, it CAN add to its cache the settings from “browser cache” page, so I am sure there’s a workaround here, for someone so skilled to CODE W3TC…! ? Yep.

2) Whether or not you and he agree on point 1) (= regardless), an absolute must is that w3tc excludes the /wp-admin path pages from adding Security Headers declarations to its cache.
Think: There’s “millions” of plugins and themes for wordpress, and there’s no way I (anyone?) is ever able to devise a workable security headers section when using w3tc if w3tc does not exclude wp-admin pages (where frankly it doesn’t make sense ANYWAY).

We have just been through sth that lacks words allowed in this forum….
so tough that job is with w3tc (and only with w3tc, because other caching plugins I know don’t offer this at all, hence they don’t “overrule” any settings in functions.php, I believe?).
All the time we get “surprised” with inexplicable new challenges, so much so that plugins stop working (obviously) because a single declaration “forbids” them. Which crashed in certain cases the entire site (eg membership plugins…).

So, 2) is a MUST. Until that is resolved, we can only either a) stop using w3tc, or b) use it but have to forgo all security headers that we *already* have in functions.php anyway (but w3tc as said “overrules” them).

Thanks so much Gido!!

Hi,

Please were you guys able to resolve the above issues?

I seem to be experiencing a similar issue. I have minify disabled but W3 total cache seems to still create cache files.

I am getting the below error in GT Metrics.

Avoid bad requests:

The following requests are returning 404/410 responses. Either fix the broken links, or remove the references to the non-existent resources.

https://headlines.ng/wp-content/cache/minify/38215.js
https://headlines.ng/wp-content/cache/minify/dd5f0.js
https://headlines.ng/wp-content/cache/minify/df983.js

I have checked the minify folder and there’s nothing in it, even went ahead to delete the entire folder. Also checked and there’s no minify database table prefix.

KeyCDN also helped me spot the error – I activated KeyCDN and noticed that when I have the ‘Host Minified CSS & JS files’ option in w3 total cache CDN settings turned on, I get the error:

Serve resources from a consistent url:

The following resources have identical contents, but are served from different URLs. Serve these resources from a consistent URL to save 1 request(s) and 206.3KiB.

https://headlines-cb76.kxcdn.com/wp-content/cache/minify/38215.js
https://headlines.ng/wp-content/cache/minify/38215.js
The following resources have identical contents, but are served from different URLs. Serve these resources from a consistent URL to save 1 request(s) and 109B.

The error goes away when I uncheck the ‘Host Minified CSS & JS files’ At the time, I had the minify enabled but was just merely using the option to combine CSS and JS file.

Having KEYCDN serve minified files made me realize W3 total cache was still serving some minified files even when I wasn’t using the minify feature.

I currently have the minify feature disabled and I’m getting the first error I pointed out.

Could there be a compatibility issue with W3 total cache and KeyCDN? @cooldavidoff also seem to have been using KeyCDN on his site if I am not mistaken?

Error 1 on GT Metrics | error 2 on GT metrics

Was a solution found @gidomanders? Thanks

Having the same issue crop up on my end. We’ve been using W3 Total Cache + MaxCDN for a few years, and just started noticing this in the last few months. Older versions of W3 don’t cause the issue. Pretty sure this is a W3 or WP issue, as those appear to be the only two things that are different here. I even have them on the same dedicated server, and only one (the older one) works properly.

It’s basically trying to load minified files from the origin site as well as the CDN version. GTMetrix returns errors for “Serve resources from a consistent url:”

Any ideas?

Let’s just hope @gidomanders or someone else from the W3 total cache will come to our rescue.

“2 months, 2 weeks ago”

Any update on this from Frederick or Gido would be much appreciated.
No file exchanges are needed, all raised W3TC issues can easily be reproduced in any new installation, incl. the Error parsing header X-XSS-Protection: 1; mode=block, 1; mode=block: expected semicolon at character position 14. The default protections will be applied.

No problem if you can’t resolve any of it: At least DISABLE all interference of W3TC with http response headers if W3TC can’t handle it correctly (it can’t, as documented). Limit caching to what caching is meant to do. Hm?

Sorry for not getting back to you guys, the issue got a bit crowded with multiple issues instead of sticking to one topic.

I fixed the X-XSS-Protection header issue and the issue with frame-src overwriting frame-ancestors. These fixes will be in the upcoming release (0.9.8).

About issues with the browsers still picking up old cached pages. What is your Cache Control policy: for HTML & XML set to? I encountered similar issues during development of one of my projects and when I changed the setting to cache with max-age and validation, the issues resolved. I think at least Chrome might be caching much more aggressive if you use any option without validation. This setting is pretty new, so older versions of the plugin don’t have such issues, but then they also don’t make your website as fast as version 0.9.7 can with the correct configuration.
Also check if the ETag header is included. Here’s a good explanation about how caching works and why the ETag header is important: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching

I think the preloading CSS issues might also be related to what I explained above. If you disabled Minify, preloading should not be happening. You might have used Minify before. If you’re using full NginX or NginX as proxy, please reload the NginX configuration, as it might be caching the responses or still be running an old configuration.

If you are still having issues, please open a new topic, as this topic has become unclear.