In the admin_menu module, when flushing css and javascript cache, it runs this code:

_drupal_flush_css_js();
drupal_clear_css_cache();
drupal_clear_js_cache();
cache_clear_all('*', 'cache_page', TRUE);

However, with the new CDN module it only flushes the CSS cache when drupal_flush_all_caches() is called. This problem got introduced when the location of the css files was moved to public://cdn/css/http. Can you explain why this was done. Why not just keep the css files in public://css?

Also, there is a lack of any upgrade notes about the change of the location of the css files. I have my public://css directory mapped to a NFS mount (for use in the webserver farm). I had to add another mapping for public://cdn/css/http after some debugging to understand what the CDN module was now doing. Once again, this could have been avoided if the css files were kept in public://css.

Comments

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Category: bug » task
Priority: Normal » Minor

Because we need to have different aggregates for HTTP vs HTTPS. Drupal 7 core is broken in that regard. This is not something that is a bug in the CDN module, it's a bug in Drupal core.

You're right though that the files *could* live in public://css/(http|https) instead of public://cdn/css/(http|https). The reason I put it in a new directory is so that all files generated by the CDN module, whether CSS or something else, could live there.

You're also right that there should be docs. However, the number of people storing a *subset* of public:// on an NFS mount is minuscule. I strongly doubt that's even recommended because it can lead to multiple web servers generating the same aggregates. Since it's such an edge case, I'll leave it up to you to provide a patch to update the README to document this. You can then word it in a way so it is clear to everybody else in the same position as you.

ttkaminski’s picture

ttkaminski commented

Placing the files in the public://css/(http|https) will cause cdn version of the cache files to be deleted when the css cache is flushed, which is good. But what about these function calls:

cdn_get_blacklist(TRUE);
variable_del('cdn_css_cache_files_http');   
variable_del('cdn_css_cache_files_https');

Which are called in cdn_flush_caches(). Do they need to be called when the css cache is flushed?

khiminrm’s picture

khiminrm commented

Hi! I have the same issue when clearing the cache for js+css with drush command.
Is there any way to clear css cache without clear all cache.
We are using CDN only for images. Can I somehow prevent CDN module from storing .css files in it's custom directory?
I've tried to put the string 'sites/default/files/css' in Exceptions on the page "admin/config/development/cdn/other". But no luck.
Thanks!

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: Flush CSS and Javascript in admin_menu doesn't work » Flush CSS and Javascript in admin_menu doesn't work with the CDN module
Project: CDN » Administration menu
Version: 7.x-2.6 » 7.x-3.x-dev
Component: Module » Code
Category: Task » Feature request
Issue summary: View changes

Actually, the CDN module implements hook_flush_all_caches(): http://cgit.drupalcode.org/cdn/tree/cdn.module?id=7.x-2.6#n468. The admin_menu module should just invoke that hook. But then it'd clear more caches, and it doesn't want to. The only way to fix this, is for the admin_menu module to check if the CDN module is present, and if it is, invoke cdn_flush_all_caches() as well.

tyler45’s picture

tyler45 commented

a simple solution for anyone with commandline access is to run

drush php-eval "cdn_flush_caches();"

instead of

drush cc css-js

truls1502’s picture

truls1502
he/him
Primary language Norwegian Bokmål
commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +postponed2w

I am sorry for no reply until now.

There are many issues regarding this module admin_menu which is a bit difficult for us to follow up since some of the issues might be already outdated, or is already fixed by the module or any other modules or itself core which means that the problem might no longer need to be fixed.

We can see that the issue has been created for a few years ago, I hope it is okay for you that I am postponing the issue, and give you around two weeks. If you still face the problem, could you tell us the step by step when until you get the error message or what is frustrated you, and a list of modules you are using related to admin_menu and a screenshot that might help us? So it makes us easier to reproduce your issue.

However, after two weeks with no feedback - we will close this issue. So in case, you noticed it after the issue is closed, do not hesitate to reopen it like and fill information which is mentioned above.

So before giving us a feedback, do you mind to test it again with our latest 7.x-3.x-dev?

Thank you for understanding! :)

truls1502’s picture

truls1502
he/him
Primary language Norwegian Bokmål
commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
Issue tags: -postponed2w

This issue has been automatically marked as closed because it has not had recent activity after the last post.

However, if you or someone is still facing the same issue as described to the issue, could you please to re-open the issue by changing the status of the issue, and add an explanation with more details which can help us to reproduce your situation.

Again, thank you for your contributions! :)