Can't Clear ctool's CSS cache through Drupal interface [#426652]

When clearing the Drupal cache, ctool's CSS cache persists. I dug around for a way to clear it through the Drupal interface, but after failing to find anything decided to manually truncate the table.

Unless there's something I'm unaware of, shouldn't this module's cache be cleared when the core system's cache is cleared?

Thanks!

Comments

Comment #1

molenick CreditAttribution: molenick commented 7 April 2009 at 18:30

To be a little clearer on how I found this bug, I was migrating a site for a client from a single site config to a multisite one. Previously, the panels module had some CSS that was cached and pointing to a background image in "sites/all/modules/panels/*". During my migration, these modules were moved into "sites/[client_site]/modules/panels/*".

Usually when this happens visiting the /modules or /themes directory clears it up, but some digging with Firebug showed it to be linking the CSS out of the files directory. Clearing the cache and deleting the CSS files didn't work.

Not sure if it's handy to have ctool's cached CSS update when the location of a module changes, it will probably only happen during early development or migrations, but that is the root of this issue. If it's worthy of another report, I'll file one but it's probably small enough to let slide.

Comment #2

merlinofchaos CreditAttribution: merlinofchaos commented 7 April 2009 at 18:34

Oh that's a very interesting issue. I think you're right that there needs to be a tool to take care of this.

It should be relatively easy to form_alter a cache clear onto the performance page and clear that cache. I do not believe it should be auto-cleared during a normal cache clear, as that happens *way* too often and the CSS is not affected by normal content updates, but you did find an update that does affect it. It may also simply be enough to force a cache clear when the modules page is submitted, though I don't think that will necessarily pick up module moves, and that is going to be important here.

Thanks for the heads up. This is relatively minor but still important.

Comment #3

pokurek CreditAttribution: pokurek commented 18 April 2009 at 16:49

And what about using hook_flush_caches() for modules _cache tables?

Comment #4

merlinofchaos CreditAttribution: merlinofchaos commented 24 April 2009 at 00:15

That's only for cache tables to be used with cache_get and the like. The css cache CTools uses is meant to be involatile; if you clear it, the CSS won't be automatically regenerated so it'll just make things break really badly. I advise against that.

Comment #5

westbywest CreditAttribution: westbywest commented 4 May 2009 at 17:10

Bump.

The suggestion to use hook_form_alter() to add a checkbox to the admin/settings/performance page seems like a reasonable way to give the user a way to refresh ctools' involatile CSS cache, and I would propose that this instance of hook_form_alter() reside in the very same code that is generating the CSS cache in the first place.

I just spent several hours tracking down a styling problem with a panels implementation, with much of the difficultly stemming from A) indirection from panels module depending on elements of the ctools module, B) no indication in the panels UI that a CSS cache was being generated, and C) filenames like sites/default/files/ctools/css/d5edea5c7eb5c110521907c92306d607.css not allowing for very intuitive debugging of uncooperative stylesheets, especially when "panels," the module that ultimately requested the cache, appears nowhere in the CSS file's name or path.

Comment #6

merlinofchaos CreditAttribution: merlinofchaos commented 5 May 2009 at 23:18

Status:

Active

» Fixed

After studying the code, I decided my response in #4 was incorrect, and that hook_flush_caches() is actually the correct way to go about it. I've just checked this clearing in. This should also be caught by devel's cache clear as well.