Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hi!
* I upgraded to CDN 7.x.-2.3
* I went to the website and all images being displayed via the CSS files were missing.
* I checked out the 7.x-2.x branch from git and my images came back after I went back to the commit:
143e46e196d323dd986d8cee7058905a4d9aa771 So I determined that the problem was in the next commit.
It comes down to the new security tokens added to the URL. The changes made were:
File: cdn.module
Function: cdn_file_url_alter
AND
File:cdn.basic.farfuture.inc
cdn_basic_farfuture_download($token, $ufi, $path)
* The images come back when I comment out the check for security token.
* I also noticed that the images I'm getting once they show up agian have the exact same token as the css file that is calling them
* We do not have css aggregation turned on.
I'm happy for any suggestions! :)
Jaime.
Comments
Comment #1
Wim LeersI forgot to document this; sorry. You have to rebuild your menus, so that the new Far Future URLs actually work, plus you have to clear the CSS cache so that the file URLs in the CSS files (usually to images, but also fonts, for example) are updated to the new style.
You can do that:
- with Drush:
drush cc menu && drush cc css+js.- just through Drupal's UI: submitting the modules page and clicking "Clear Cached data" at admin/settings/performance in D6 or clicking "Clear all caches" at admin/config/development/performance in D7
Now documented in http://drupal.org/node/1441480 and http://drupal.org/node/1441482.
Comment #2
Wim LeersComment #3
Wim LeersComment #4
jaime@gingerrobot.com CreditAttribution: jaime@gingerrobot.com commentedThankyou for the quick response Wim! I did do a drush cc all when I updated the module. I also ran an updatedb and cron as well.
The two key things I noticed during my testing:
1. The security token given to the images served is the same token that the css file has.
2. The images are not being passed through cdn_file_url_alter(&$original_uri). I logged all content having their urls altered and none of the images came into the logs.
Comment #5
Wim Leers1. I just noticed this happens for files that have not been aggregated.
2. Which images? CSS background images? If so, this is the same bug as #1.
Working on this, even though I really don't have time for this.
Comment #6
jaime@gingerrobot.com CreditAttribution: jaime@gingerrobot.com commentedThankyou for your help Wim,
It looks like all the images in the css file are background images.
I hope this helps other CDN users as well.
Jaime.
Comment #7
Wim LeersWhile fixing #1442096: Fallback mechanism (for Drupal 6) broken in version 2.3, I first ran into #1442406: Images with query strings not rewritten in fallback mode or when scanning node bodies for images, which I'd never seen before and must've been happening all along. Then I fixed #1442096: Fallback mechanism (for Drupal 6) broken in version 2.3.
Then I ran into the problem reported at #4. This is caused by #1428530: Override CSS aggregation to ensure correct file URL altering for files referenced by CSS files, and I've just posted patches that solve this at #1428530-13: Override CSS aggregation to ensure correct file URL altering for files referenced by CSS files.
Comment #8
jaime@gingerrobot.com CreditAttribution: jaime@gingerrobot.com commentedHi, I've tried your patch on the release for 2.3 and on the current git. Neither seems to fix the problem. I still see same sec token in the urls for both css file and all the background images it's calling for.
I'll investigate a bit more and see if I can find anything new taking into consideration the changes you've made.
Thankyou,
Jaime.
Comment #9
Wim Leers@jaimekristene: Did you clear the CSS cache?
Comment #10
theunraveler CreditAttribution: theunraveler commentedI also tried the patches (and cleared menu and css+js caches) on both 6.x-2.x and 6.x-2.3 and the issue was not fixed.
Comment #11
Wim Leers#10: can you describe the exact nature of your problem by posting some of the problematic URLs?
Comment #12
Wim LeersOh and with the CSS aggregation changes, you may also want to rebuild your theme registry.
Comment #13
Wim LeersThe follow-up patch for #1428530: Override CSS aggregation to ensure correct file URL altering for files referenced by CSS files that I mentioned in #7 should have fixed this.
Comment #14
jaime@gingerrobot.com CreditAttribution: jaime@gingerrobot.com commentedI just tested the latest version from git.
commit a4ab5ea350c0c4051b1bf062b1a006f1a4974476
This issue is still not fixed for me. What I am still seeing is images being requested by CSS files have the same token as the css file itself.
We have turned the far_future module off for now.
I always do a drush cc all before testing anything.
Jaime.
Comment #15
Wim Leers#14: I believe you think you did everything right, but I'm convinced you made a mistake somewhere. There's custom CSS aggregation now. It's near impossible that it works for everybody except for you. Also, the relevant issue is actually #1428530: Override CSS aggregation to ensure correct file URL altering for files referenced by CSS files, not this one.
Maybe the APC cache is messing up your results? I've seen this happen too. See http://stackoverflow.com/questions/911158/how-to-clear-apc-cache-entries on how to clear it.
Are you using the AdvAgg module maybe?
It would be even better if you could do a vanilla Drupal installation and give that a try.
Comment #16
andreiashu CreditAttribution: andreiashu commentedHi Wim,
Shouldn't we have a checkbox in the Admin UI to enable the 'cdn_theme_layer_fallback' variable? Basically a user has the ability to enable far future URLs but doing just this WILL break their images that have relative URLs in CSS files. So, if one doesn't have other helper modules (like advagg + parallel css module enabled) one should be informed that she needs to enable 'cdn_theme_layer_fallback' as well. In this case a checkbox just beneath the far future option would make sense?
Let me know your thoughts.
Comment #17
andreiashu CreditAttribution: andreiashu commentedI forgot to mention: I'm seeing this from a D6 point of view - although the settings should be the same for D6 and D7?
Comment #18
Wim Leers1) There's no fallback mode in D7. Fallback mode only exists to not require patching core. Patching core is only necessary in D6. Hence this mode only exists in D6.
2) Fallback mode is enabled automatically. See
_cdn_requirements_detect_fallback(), which is called automatically for every CDN admin page. Users will have to visit the CDN admin page to configure it in the first place, hence this function will be called. If it's never called, then no CDN integration happens anyway, so nothing breaks.3) I don't see why this would break relative URLs in CSS files? Fallback mode + Far Future expiration works just fine. Parallel CSS is obsolete.
Overall: yes, things are hackier in D6. But that's because of the fallback mode, which I only added to remove the need for patching core for those who can't/don't dare or know.
Comment #19
jaime@gingerrobot.com CreditAttribution: jaime@gingerrobot.com commentedHi!
Thankyou Wim for being very patient with me. I have figured what was going wrong for me.
I read your messages on the other ticket http://drupal.org/node/1428530#comment-5558316
In my dev environment I have 'preprocess_css' => FALSE AND 'cdn_farfuture_status' => TRUE
I needed "Aggregate and compress CSS files"/'preprocess_css' => TRUE for far future to work.
Sorry I didn't read the other ticket properly before now.
Thankyou again.
Jaime.
Comment #20
Wim LeersI'm glad you appreciate my time :)
Also: you've just made an extremely good point: I need to document that you need to enable CSS aggregation for Far Future expiration to work well! I just did that:
- D7: http://drupalcode.org/project/cdn.git/commit/4946c7e
- D6: http://drupalcode.org/project/cdn.git/commit/e4b7256