Posted 7 months ago #
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.
Posted 7 months ago #
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.
Posted 7 months ago #
Does anyone know anything about this - is it most likely a misreporting fault with "yslow" or is this a known W3TC issue?
Posted 5 months ago #
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.
Posted 5 months ago #
Mail Fredrick himself, for he is not answering here at the forum
Posted 5 months ago #
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.)
Posted 5 months ago #
Hi @sadhaka are the static components related to your website or other websites?
Posted 4 months ago #
I have the problem too. Components related to my website
Posted 4 months ago #
@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.
Posted 4 months ago #
@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.
Kind regards
Posted 4 months ago #
@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.
Posted 4 months ago #
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.
Kind regards
Posted 4 months ago #
@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?
Many thanks.
Posted 4 months ago #
@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.
Kind regards
Posted 4 months ago #
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?
Confused.
Posted 4 months ago #
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.
Posted 4 months ago #
This is the result of webserver configuration (modules etc...) I think. I have good .htaccess and xx3 static components without a far-future expiration date too
Posted 4 months ago #
@Gans-S Aha - so it may be a deficiency with the server configuration I'm using? Something not installed? What would be the absent culprit for this problem?
Posted 4 months ago #
@sadhaka can you find out if your host provider offers mod_expires on shared hosting?
Posted 4 months ago #
I discover that mod_expires isn't supported on my shared server. So that's the reason that 'expires headers' isn't working I guess?
Posted 4 months ago #
@sadhaka, yes that is correct. If mod_expires is not supported then you can not set this option using this plugin.
Unfortunately your sever has this limitation that the plugin cannot control.....
Could you close this ticket even though it is not resolved if you don't mind.
Kind regards
Posted 4 months ago #
Well thanks for the insight.
You must log in to post.
