clear all AKAMAIs urls at cron run

Thank you for your notice.

My actual problem is that I use the module fastcache_path for creating static pages, and I want to use CSS/JS aggregation too.

Then, when somebody clears the Drupal cache (using the corresponding entry of admin_menu), all CSS/JS aggregated files will be removed, and all the fastcache pages will also be removed, but the AKAMAI cache still holds the fastpath page with references to the aggregated files.... do you understand me ?

How do you work with AKAMAI + aggregation of CSS/JS ? Everytime that a "clear all cache" command is sent to DRUPAL, I need to clear the AKAMAI cache because all references to CSS/JS will not longer be valid, what else can I do ?

Thank you.

Febbraro,

I forgot to tell you that I do not really know how to do this:

"You can actually instantiate the Akami class yourself and give it the proper parameters to clear via CPCODE instead of ARL."

Although I am PHP developper, I do not have access to AKAMAI documentation at this moment, so I do not know the "proper parameters..." :(

No, I have not found a solution using the AKAMAI module. I have not tried to implement the "clear by CPCODE" that was suggested here.

Besides, we use a netstorage server to which we feed all our images and "files" directory and afterwards in our AKAMAI configuration we rewrite the URL paths meaning that for everything that is under "files", the requests do not ever reach our DRUPAL servers, so when we do a DRUPAL cache clear all, I have to manually launch my syncronization script at regular intervals to make sure that "all" aggregated CSS/JS files will eventually reside on the netstorage server. If you use a lot of drupal_add_css / drupal_add_js functions, the corresponding aggregated file will be modified at an unexpected time in the future (when those functions get to be executed), so I recommend you to avoid using them and instead put all your CSS and JS files inside your "theme".info file, this way the aggregated file will not change over the time and you CSS/JS directory will not be too populated...

The sulutions that I can imagine without modifying this AKAMAI module would be:

* Don't rewrite the URL for the css/js directory (if you don't use netstorage then this is not a problem for you)
* Add an AKAMAI header Edge-Control: No-Store when you serve CSS/JS aggregated files (or modify the AKAMAI xml configuration to do this).

So in my humble opinion, if you want to avoid problems with CSS/JS aggregated files => exclude them from the AKAMAI cache !! :)

But now that I am re-thinking about it, this is not enough, because AKAMAI would have cached pages with references to CSS/JS aggregated files that DRUPAL removes when you issue "cache clear all", so you are right that it is necessary to modify DRUPAL to keep the old versions. In my opinion is not a bad idea, it is the right thing to do, until somebody modifies this module to allow a "clear all AKAMAI cache by CPCODE".

But as febbraro said in #1, AKAMAI takes 15 minutes to make the clear by CPCODE, and your site could experience a peak of requests, so we would also need to modify DRUPAL to not erase the CSS/JS cache at cron run.

I think we should reopen this issue, at least it is clear that this module needs a "clear by CPCODE" (if AKAMAI allows to implement this), but it is also clear that even with this feature, DRUPAL will still have to be modified to make it work smoother with an AKAMAI typical usage.

Hope this helps,