Coming from #504552: Problems with panels styles CSS and JS on cached pages.. Hook_flush_caches() is being run by system_cron(), so every cron run CTools CSS files are removed. Not only this is bad idea, but also it breaks cache strategies which don't involve cache_page clearing on cache_clear_all(NULL, "cache_page") (e.g. Memcache API).

Comments

crea’s picture

crea commented

I've just tested that it also breaks "minimum cache lifetime" setting with core cache.inc. I've also verified that temporary ugly workaround fixes this problem for "minimum cache lifetime" setting too.
Basically any cache logics which doesn't do immediate flushing of cache_page table/bin is going to be broken.

merlinofchaos’s picture

merlinofchaos commented

Interesting. Maybe I misunderstood how hook_flush_caches is supposed to work, then, because I didn't think it happened every cron.

merlinofchaos’s picture

merlinofchaos commented

Well crap. That is absolutely ridiculous design on core's part. Plus, the fact that this is called on cron is completely undocumented.

But that said, that should flush the page cache at the same time that our CSS cache gets flushed, shouldn't it? How come this doesn't totally break all caching? This is very confusing.

And if we do this, then we no longer will be able to clear the CSS cache with devel's "clear caches" button, which is important.

merlinofchaos’s picture

merlinofchaos commented

Ok, after some discussion with Moshe and sdboyer, I understand now that the cache clear that happens on system cron may not always clear the page cache. I agree this is ultimately probably causing that problem, and Drupal gives me no way to check to see what kind of cache flush we're doing.

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Subscribing, seeing this issue as well with latest (6.x-1.3) CTools and CSS aggregation enabled.

EDIT: I'm testing the patch from #504552-119: Problems with panels styles CSS and JS on cached pages. - will post back with results.

ianchan’s picture

ianchan commented

subscribe

rismondo’s picture

rismondo commented

subscribe

hongpong’s picture

hongpong commented

Subscribing - I had issues with mini panels CSS maybe getting caught possible because of this - crossposting the related issues (not trying to spam)
The main thread for Panel Nodes #504552: Problems with panels styles CSS and JS on cached pages.
The feature req to fix mini panels/block caching is: #675844: Mini panels should tell Drupal core they cannot be cached with block caching
Duplicates of related problem #539228: Panels not displaying correctly for anonymous users // #534358: Bizarre intermittent behaviour of panels
Related cache hook issue #717036: Remove css cache clearing from hook_flush_caches() (Duplicate: #626562: Panel page's ctools CSS file may expire while page is cached - may break panel for anonymous users )

merlinofchaos’s picture

merlinofchaos commented

#8: #675844: Mini panels should tell Drupal core they cannot be cached with block caching adequately explains the problems. Why are you spreading that out onto other issues? That is rude and causes confusion. Please stop. It is completely unrelated to this.

Flying Drupalist’s picture

Flying Drupalist commented

Subscribe.

crea’s picture

crea commented

This could be fixed with a core patch to drupal_clear_css_cache(), something like

++ module_invoke_all('clear_css_cache');

Then CTools could just implement this hook.

ManyNancy’s picture

ManyNancy commented

This is not a bug that you can live with, panels is pretty unusable without its css.

What are the downsides to temporary workaround in #1?

crea’s picture

crea commented

The downside is that anonymous page cache is completely cleared every cron run

steven jones’s picture

steven jones commented

Surely the approach to CSS and JS caching is all backward in ctools at the moment?

Currently the server is trying to keep track of the css and js files sent to the client, and only send ones it doesn't already have. Putting the data in a really fragile cache though, is not a good idea. Try adding a node with a ctools modal, then click another ajax link on the same page, for example.

Isn't the client better placed to know what CSS and JS files it has been sent? Rather than store the array of sent CSS and JS file on the server in a cache, can't we send that data over to the client, and let the client decide if it should be adding CSS and JS on an AJAX request.

merlinofchaos’s picture

merlinofchaos commented

#14: Your comment is interesting and valuable...and totally on the wrong issue. Please post this somewhere more relevant so we don't take over an important conversation.

steven jones’s picture

steven jones commented

Sorry merlin et al. there are too many levels of caching to keep track of these days.

eugenmayer’s picture

eugenmayer commented

Well just back on the issues, yes that causes problems. AFAIK there is an open issue in panels or ctools, where ctools generated CSS files are not included after cron run. you have to clear the cache to get it back working. The css file with the hash name is simply missing on the FS, but i.e. still in memcache cachepages somehow.

I think this could be related to this.

Chris Einkauf’s picture

Chris Einkauf commented

Subscribing.

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Fixed

I added a check for the CRON semaphore (not sure why I didn't see that the last 20 times I looked at this). That may finally get rid of this issue. Keeping fingers crossed.

crea’s picture

crea commented

I'm afraid this is only a weak workaround. Any module could invoke hook_flush_cashes() just to gather information (this is an informational hook).
But it's much better than nothing ofcourse. We have to live with it in the absence of the other reliable solution.

merlinofchaos’s picture

merlinofchaos commented

I agree, but I would like to point out that the way the hook is named and the documentation for the hook do not actually make it appear to be an informational hook. I personally feel this is a bug in core, and we are simply working around it as best we can. We should check to see if this behavior is changed in D7 -- I think there may be an issue but I haven't the time to go find it right now.

Status: Fixed » Closed (fixed)

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