Scenario:
1. using CSS aggregation and HTTPS CDN (on drupal 7.14).
2. A CSS file is updated (not a new file, just its content)
3. performing clear cache.
4. when surfing to the site it the page is using OLD aggregated CSS instead of creating a new one and use it.

this happens only if using https as CDN. I did some research and i think its because the CDN module is using its own css cache parameter named 'drupal_css_cache_files_https' instead of drupal's css cache parameter name 'drupal_css_cache_files' (without the '_https').

When I removed the '_https' everything worked just fine.

Please confirm

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Wim Leers’s picture

Title: CSS aggregation with HTTPS + clear cache wont update the aggregated css » CSS aggregation with HTTPS + clear cache: CDN's CSS cache not actually cleared
Assigned: Unassigned » Wim Leers
Status: Active » Postponed (maintainer needs more info)

It's necessary to have a separate CSS cache for HTTPS. But you're absolutely right that this needs to be cleared simultaneously. Unfortunately, it seems Drupal core does not provide such a facility… (i.e. there's no hook that allows us to know when these caches are cleared).

Wim Leers’s picture

Priority: Major » Minor
Status: Postponed (maintainer needs more info) » Active
Wim Leers’s picture

Status: Active » Needs review
FileSize
2.37 KB

Please test this patch. It works fine for the HTTP case, and should also work fine for the HTTPS case.

Note that Drupal's CDN cache clearing uses http://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_d..., meaning that stale files only get deleted after 30 days by default.

ahb’s picture

This patch is not working for me. When I have CDN enabled in its settings I cannot clear cache and get css changes. As soon as I set it to disabled, I can change css, clear cache, and see my changes. It doesn't appear to matter if I am in https or http mode, as soon as the aggregated css path is changed to include the cdn/css/http or https folder the css is not updated.

Wim Leers’s picture

Drupal *always* maintains the CSS/JS cache for AT LEAST 30 days, even if you clear it! "Clearing" the cache for the CSS/JS cache means: "delete all CSS/JS cache files that are older than 30 days". There is a reasoning behind that, too (old CSS/JS cache files should remain around for a while, otherwise Google's cached pages will break) — you don't have to agree with it, but that's how it works in D6/D7 core.

So: can you please put in a CSS/JS cache file that's >30 days old and test again?

See the following if you don't believe me:
- http://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_c...
- http://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_c...
- http://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_d...

ahb’s picture

Hi Wim,

Thank you for your response. I was mistaken, this is indeed working. I was getting tripped up by the page cache lifetime in my testing. Going to a new page that did not have cached reference to the existing css aggregate does get a new css aggregate containing my css change.

I am not sure that this is actually related to what you have changed in the patch though. The original issue report sounds like what I am seeing, but the patch appears to fix the issue of the aggregates never being deleted, even after the 30 days elapses.

liozn can you try turning your page caching off and test again? It should generate new aggregates and reference those on page render.

Wim thanks for this awesome module, it's going to help us out a lot!
-Aaron

Wim Leers’s picture

Status: Needs review » Reviewed & tested by the community

The original issue report sounds like what I am seeing, but the patch appears to fix the issue of the aggregates never being deleted, even after the 30 days elapses.

This is indeed precisely what the patch is addressing.

And indeed, that's not precisely what the original report was about. But that's how I uncovered the problem. The specific problem the original report was about is in fact "by design"… The only way around it is to SSH into your server and manually delete those files — or create a module that can do it for you.

Wim Leers’s picture

Lux Delux’s picture

Hi, I have just updated to the last dev release and I don't know if it's connected with this problem but clearing my cache doesn't do anything. The old css files are still being served. In the previous version I just cleared cache and the css changes would show up.

I'm not using https but normal http.

Wim Leers’s picture

D7, CDN 2.5 or dev?

Lux Delux’s picture

Ooops sorry didn't notice it was for both Drupal 6 and 7.

Drupal 7, dev.

Works fine with 2.5

Wim Leers’s picture

So you're saying it works in 2.5, but not in dev? All on D7?

Lux Delux’s picture

Yes, exactly.

It also worked with the previous dev release, basically before this commit it seems.

Wim Leers’s picture

Status: Fixed » Active

Hm. Stupid :( Reopening.

Maybe you're looking at pages that are still cached.

Please make sure that 1) sites//files/cdn/css/http actually exists *and* contains CSS files, 2) your pages are pointing to CSS files inside that directory!

Lux Delux’s picture

I've cleared both browser cache and flushed the Drupal caches. Aggregation of css is on.

It points to sites//files/cdn/css/http properly, I've checked with Chrome's inspector.

Basically everything is as before but flushing the cache does not update the css.

Wim Leers’s picture

Status: Active » Postponed (maintainer needs more info)

You *did* read #3 and #5, right?

If you don't believe me, try clearing the cache without the CDN module installed. I'm pretty sure that not being aware of #3/#5 is what's (rightfully!) tripping you up :)

Lux Delux’s picture

I did read it again just now but I still don't understand why then did the previous version, when clearing the cache, return the new css in my browser?

When I update my css without cdn, which I do a lot, all I have to do is refresh the page in the browser and it's applied. When viewing the page as a visitor I have to clear the caches as it's cached by boost. I disabled the drupal caching on the performance page.

So basically I only use boost to cache my pages, and the browser does it's own caching of css etc. files.

So nothing changed on my end except the CDN module and I'm getting confused :)

EDIT: I guess I'll delete the css files in the sites/default/files/cdn/css/http/ folder manually each time I update something. Would that be the advised approach?

Wim Leers’s picture

Status: Postponed (maintainer needs more info) » Fixed

#17: Because your files were probably >30 days old. I'm certain that if you try to change some CSS, then clear the cache, then reload the page, then do it again, that the second time will not work, because the files are only a few minutes old, not days.

For now, I'm closing this issue. If you can reliably reproduce your problem on a vanilla Drupal installation with the CDN module, please create a new issue.

Your suggested approach is indeed advised, that's also what you have to do without the CDN module… Strange, but true — and also for a good reason: see above.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

mropanen’s picture

Status: Closed (fixed) » Needs review

Shouldn't the variable_dels in cdn_flush_caches() be like

variable_del('cdn_css_cache_files_https');
variable_del('cdn_css_cache_files_http');

or have I totally misunderstood what's happening there?

desmondmorris’s picture

@mropanen I think you are right. I noticed this when I read through the patch and noticed that the variable name had been changed. The patch from #3 looks to have been committed back already. Here is the patch with the variables updated in the cdn_flush_caches function.

Status: Needs review » Needs work

The last submitted patch, cdn-css_cache_expiration-1634932-21.patch, failed testing.

Berdir’s picture

Title: CSS aggregation with HTTPS + clear cache: CDN's CSS cache not actually cleared » CSS aggregation cache clear broken (was: CSS aggregation with HTTPS + clear cache: CDN's CSS cache not actually cleared)
Version: 7.x-2.5 » 7.x-2.x-dev
Priority: Minor » Critical
Status: Needs work » Reviewed & tested by the community

Confirmed, CSS cache clearing is currently completely broken because of the wrong variable names.

Patch applies and works, I guess it didn't apply because this issue was against 7.x-2.5. Will trigger a re-test.

Berdir’s picture

jemond’s picture

I have deployed this patch to production and can confirm it fixes the issue (over HTTP).

netes’s picture

Tested patch over 7.x-2.x-dev and it works fine.

Josephnewyork’s picture

Tested patch over 7.x-2.x-dev and it works fine.

Wim Leers’s picture

Status: Reviewed & tested by the community » Fixed

D'oh. That's a really stupid typo. Thanks! Committed & pushed.

http://drupalcode.org/project/cdn.git/commit/c67f273

(I credited you, @mropanen, because you pointed out the fix. Congrats with your first commit on d.o! :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.