• First off a compliment, I had already sent this image as email, but for everyone:
    https://www.dropbox.com/s/8ytzvy2tlxmak14/with-and-without-w3tc.png?dl=0

    Formidable impact of activating w3tc with the right settings, huh?

    Now my support question, to anyone having experienced the same and (hopefully) having found a solution?

    >>> On the site I am speaking of, we are not using w3tc minify, none of it, but in every test (gtmetrix as an example) the same 5 “bad requests” show up, to files that don’t even exist:

    /wp-content/cache/minify/1c235.css
    /wp-content/cache/minify/69faf.js
    /wp-content/cache/minify/82053.js
    /wp-content/cache/minify/8cba1.js
    /wp-content/cache/minify/c9f75.js

    Clearly they originate from the time when we tested the impact of all sorts of different settings (and not only w3tc), at which we did test w3tc minify as well, yes. We have to do extensive testing, we make a living from making wordpress websites fast. But normally at the end of testing all old links to files get deleted. These ones though we cannot find where/when/by what they are called such that speed tests (and console/network) show them despite non-existent.

    It is clear to me that the files belonged to w3tc earlier. But countless cache purges later, and the links still exist somewhere. We even re-installed w3tc, but no luck.
    Does anyone have experience why, or how to get rid of them?

    Again, the files do not exist, no, there is not even a minify folder anymore as we figured we don’t need that.

Viewing 4 replies - 16 through 19 (of 19 total)
  • Plugin Contributor gidomanders

    (@gidomanders)

    I come back to the X-XSS-Protection header issue, that was not actually an issue with W3 Total Cache. We don’t add the header twice. You probably set your own header somewhere, while W3 Total Cache is also setting that header, resulting in 1; mode=block, 1; mode=block. It is only supposed to be 1; mode=block.

    So what you can do to resolve that issue is you go to Performance => Browser Cache, deselect the X-XSS-Protection option and save settings. That will disable the header by W3 Total Cache, leaving the other one intact.

    Thread Starter CoolDavidoff

    (@cooldavidoff)

    Thank you so much Gido!!
    – I reviewed your google link
    – will also review the upcoming release (0.9.8)
    – and will open a new topic if needed, as you suggest

    Thank you

    Plugin Contributor gidomanders

    (@gidomanders)

    We found out what is the cause of the remaining preload links. There’s .htaccess files in the cache directory which include the preloading headers. You can delete those files and reload the website. This should resolve your initial issue with

    5 “bad requests” show up, to files that don’t even exist:

    /wp-content/cache/minify/1c235.css
    /wp-content/cache/minify/69faf.js
    /wp-content/cache/minify/82053.js
    /wp-content/cache/minify/8cba1.js
    /wp-content/cache/minify/c9f75.js

    Plugin Contributor gidomanders

    (@gidomanders)

    Those .htaccess files should be removed automatically, but that’s not happening. We’ve listed the issue and will try to fix it as soon as possible.

    For now if anyone encounters the same issues, please remove all the .htaccess files in the wp-content/cache directory you can find.

Viewing 4 replies - 16 through 19 (of 19 total)
  • The topic ‘W3TC: non-existent js and css in cache/minify/ throw errors’ is closed to new replies.