[Resolved] [Plugin: W3 Total Cache] Does W3TC write expires headers?
If I run ‘yslow’ on my blog (with W3TC installed) it tells me that I should add expires headers (gives me a Grade F because they’re not there – “There are 40 static components without a far-future expiration date.”).
But doesn’t W3TC take care of all that? Perhaps it doesn’t. Sorry if I have that all wrong.
I should have mentioned that I’m not using a CDN. Any reason why YSLOW gives me this message? I’ve enabled “Set expires header” for all options.
Does anyone know anything about this – is it most likely a misreporting fault with “yslow” or is this a known W3TC issue?
Does anyone know whether W3TC is supposed to have this “expires headers” covered? I get the impression it should, but Page Speed and YSlow consistently complain about many “static components without a far-future expiration date”.
If I have this wrong and W3TC isn’t even supposed to enable this, or if it is and I therefore have a problem I’d love someone to explain it to me.
Mail Fredrick himself, for he is not answering here at the forum
Well, it is a little disconcerting that Fredrick is the only person in the WordPress universe that seems able to offer any advice about this.
Does no-one apart from this author guru have *any* clue about this?
By the look of the support page, emails with questions are charged for. (Last resort, I’m afraid.)
Hi @sadhaka are the static components related to your website or other websites?
@mbrsolution – Hi – most are related to my site – theme images, uploaded images for posts (many of these), but also some plugin css files; social widget files; even some minified w3tc files. It looks to me like everything really.
@sadhaka, have a look at this link from this forum http://wordpress.org/support/topic/w3-total-cache-isnt-working-at-all
I hope this helps you.
@mbrsolution – I took a look at that post, and from what I can understand, the gist of it was to check that the rewrite rules specified at the bottom of the “Install” section are indeed written to my .htaccess file, and they are.
My WP installation is (like many others), installed into a sub-folder from the site root. But the .htaccess at the site root contains all the code specified in the “Install” section.
I don’t have another .htaccess file in the WP sub-folder. Should I have?
So anyway, if I understand the main message of that post correctly, its recommendations don’t apply to my installation, and YSlow still gives me an ‘F’ for “Add expires headers”, complaining that “There are 36 static components without a far-future expiration date”, as before.
Hi @sadhaka, yes you should have another .htaccess in the sub folder. In my humble opinion every WordPress installation should have its own .htaccess even if it is in a sub-folder unless you are setting it up differently i.e you install your WordPress in a sub-folder but you place the .htaccess in the root and point it to a subfolder for security reasons.
However when you have 2 WordPress installed like I have one in the root and another in the sub-folder, they both have their own .htaccess file. One WordPress is setup in English and the other is setup in Spanish.
I hope this helps you.
@mbrsolution Thank you – I must confess I don’t understand the rationale for having two .htaccess files which both do the same job, but I don’t know enough about it to judge, and perhaps indeed you are right.
But does this mean that both .htaccess files (the one in the site root and the other in the WordPress subdirectory) should contain the rewrite rules specified at the bottom of the “Install” section, as mentioned above (at least, the first block of code shown there that refers to the placing at site root)? That is, should they be identical?
@sadhaka, try and place the .htaccess file in your sub-directory where you have your WordPress installed and see what happens.
I am sure that your problem should be corrected and make sure that the .htaccess file is set to read your sub-directory and not your root directory.
But in W3TC’s “install” page, the server path that is specified in bold under “Rewrite rules” points to the root directory, not to the subdirectory.
I thought this was a reflection of the fact that in the WordPress “General Settings” my “WordPress Address (URL)” is set to the subdirectory (the “Site Address (URL)” being set to the domain root).
Minify works (I can see that in the source) and browser caching works – it’s only the expires headers thing that doesn’t. How come they work if the .htaccess file is in the wrong place?
OK, I tried it – I copied the first .htaccess code that appears under “Rewrite rules” in W3TC’s “install” page and used it as a new .htaccess file in my installation’s subdirectory, cleared W3TC’s caches, ran YSlow again and exactly the same result: it reports “Grade F on Add Expires headers … There are 34 static components without a far-future expiration date”.
As far as I can see W3TC doesn’t do this expires headers thing, maybe at least for WordPress installations in subdirectories? But whatever I do, it simply does not do it.
- The topic ‘[Resolved] [Plugin: W3 Total Cache] Does W3TC write expires headers?’ is closed to new replies.