Tell me more ×
WordPress Answers is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.
up vote 4 down vote favorite
3

I updated the style.css file of my WordPress installation recently. The change were effective: when logged in as an administrator (my blog is set so that the administrator is never served a cached version of the site, but a “live” one), I can see them.

But my blog is being served through a CDN (using W3 Total Cache). Through the CDN, the changes are not effective: the CDN does not serve the modified files from my theme. Even though I’ve uploaded them after modification (Dashboard>Performance>CDN>Upload theme files.

My CDN runs on AmazonCloud Front. And Minify is disabled on W3 Total Cache.

The theme file being served through my CDN is a compressed version: style.css.gzip

Should I “purge” objects from my CDN or wait a little more (it’s been more than a week). And yes, I empty the cache of the browser I’m using to see in the changes are taking effect. Or is there something else I’m missing?

Thanks,

P.

share|improve this question

4 Answers

up vote 4 down vote accepted

You need to either

  1. Version your files (by calling it style.css?ver=xxx.xxx) and making sure your CloudFront distribution has "Forward Query strings" turned on. This is the better option, as it means that all you need to do is increment the number in the query string and CloudFront will fetch this file automatically.

  2. Manually invalidate your files via the AWS Console (there is an invalidation tab when you edit your distribution)

To turn on 'Forward Query Strings' do the following:

  • Edit your Cloudfront distro by ticking the checkbox on the left of the 'i' and then click on the "distribution settings" button in the toolbar
  • Go to the Behaviors tab
  • Select the line, and click on 'Edit'
  • Change "forward query strings" to Yes
  • Click on "Yes, Edit"
share|improve this answer
1  
+1 But: "There are much better ways of doing it than this, see my answer" ;) – kaiser Aug 13 '12 at 22:37
1  
@kaiser yup, the datetime as the version is the best way of versioning the file. However you still need to ensure that the "Forward Query Strings" option is turned on in CloudFront, otherwise your nicely crafted version number gets ignored :P – anu Aug 13 '12 at 22:43
Thank you. I have two questions for you since I’m not familiar with this procedure. 1) The name of the “versioned” files should follow exactly the example you gave (with the question mark, the equal signs and replace all “x” with numbers of my choice) right? 2) On my AWS console for CLoudFront, I click in the “I” in the left of the table just beside the distribution I created for my blog. This allows me to access the settings of the distribution. There I can see the "Forward Query strings" is “false”. Should I replicate this “behavior” with the same values but with “true” for "For. Q. strings" – Parneix Aug 13 '12 at 22:48
1  
1. yes or you can use @kaiser's well meaning but incomplete answer to name your file. 2. I'll update the answer with the process – anu Aug 13 '12 at 22:55
up vote 3 down vote

There's a pretty simply "trick" to prevent caching, when file contents changed: Add a version number, that is set to the latest date/time you changed your file.

function wpse61738_non_cached_stylesheet()
{
    wp_enqueue_style( 
         'style-main'
        ,get_stylesheet_directory_uri().'/style.css'
        ,array()
        ,filemtime( get_stylesheet_directory().'/style.css' )
    );
}
add_action( 'wp_enqueue_scripts', 'wpse61738_non_cached_stylesheet' );

This will append ?ver=0123456789 to your style.css reference link in your header. The version number will only change, when the files contents get modified. So you have a solution that works perfect with a) server side cache b) browser cache and refreshes automatically.

share|improve this answer
Ok, that’s a really interesting option: it removes the need to manually versioned my style.css file after each modifications (which I will forget to do at one point or another). Now, if I may ask, where do I add this code? I would guess to my functions.php file? – Parneix Aug 13 '12 at 22:59
I don't know, where you need to add this code. Just search through your themes files and replace the "normal" call to the style.css file. I'll post a short update, so you can put it in your functions.php file (this still means that you need to remove the original call). And btw: This is only an addition to @anu answer. (Upvotes still appreciated :) – kaiser Aug 13 '12 at 23:01
1  
No problem! I perfectly understand that the location of this code is likely to change depending of the theme used. I’ll manage to add it to my functions.php file. I still think it’s a good complement to the solution provided by @anu. Thanks a lot for the help. – Parneix Aug 13 '12 at 23:13
up vote 0 down vote

a short answer ...

  1. Delete all your theme files and re-upload them. some times the delete action clears the CDN

  2. Yes, you could try Purge -- but Delete and re-upload is usually quicker.

  3. Also check out the settings in W3TC and in Amazon. The default Cache for in W3TC is usually 365 days. which is 31536000 seconds :)

In Amazon .. there will be a setting for endpoints to re-query the CDN. i know in Rackspace the default is 24 hours.

share|improve this answer
1  
There are much better ways of doing it than this, see my answer – anu Aug 13 '12 at 22:28
“Delete all your theme files and re-upload them. some times the delete action clears the CDN” You mean for me to delete them on my website, right? Then re-upload them in my WordPress installation. And then I guess do the “Upload theme files” again through W3 Total Cache dashboard? – Parneix Aug 13 '12 at 22:38
1  
@Parneix seriously, don't delete everything unless you have to. It almost certainly won't work unless you delete everything from the CDN as well. There are MUCH better ways of invalidating your stale CSS file – anu Aug 13 '12 at 22:41
1  
Yes, thanks! I took good note of your suggestion. I really appreciate all the help I’m getting here. Not only am I solving my issue, but I’m learning new stuff as well. – Parneix Aug 13 '12 at 22:57
up vote 0 down vote

doesn't Google tell you not to use version numbers / query strings in static files becauese it prevents browser caching?

share|improve this answer
Hum. Good point. It would be good to have more details about the way Google deals with query strings. – Parneix Aug 14 '12 at 3:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.