Closed (works as designed)
Project:
Drush
Component:
Core Commands
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
5 Sep 2010 at 15:10 UTC
Updated:
1 May 2012 at 16:41 UTC
Jump to comment: Most recent file
When you use drush cc and choose option [4] : css+js"
Drush does not update the html after clearing the cache for js and css only.
However the name of files (css and js) is not the same. The consequence is that the js and css does not work. A cache clear all work better.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | drush.cssjs_.cache_.patch | 606 bytes | donquixote |
Comments
Comment #1
moshe weitzman commentedsounds like you use page cache or block cache. don't do that while developing. in any case, use all if that works better for you.
Comment #2
doublejosh commentedSame thing. Working on an already existing site. Would be nice to be able to be able to clear page cache.
User case...
Since there is no elegant way to turn off page caching after refreshing the dev environment, I have to hit drush clear all while developing... or switch off performance via the UI every time I refreshing my dev environment.
Perhaps a "Clear CSS/JS + Page Cache" option?
OR
Perhaps a Drush command for changing your performance settings? (maybe this exists already?)
Comment #3
doublejosh commentedFor other folks who might be wondering like I was, you can turn performance caching on and off with a drush command.
drush vset cache 0Then choose 1.
This will turn if off (for example after you refresh your dev instance.
Comment #4
donquixote commentedI disagree with this being closed.
If you run "drush cc css+js" on a (production) site (to deploy minor css fixes), cached pages will be seriously broken. And the admin will not even notice, because he is logged in.
Proposed solution:
- check if page cache is enabled
- if it is, flush it.
Tagging this as "major" because it can break your site, if you are not aware of how it works.
It is likely that a lot of people have no idea.
Btw:
I wonder why there is no option in drush cc for "cache tables" or "page cache" ? Would be a good idea!
Comment #5
donquixote commentedDoes re-enabling the page cache flush it automatically?
Otherwise, it is maybe better to flush it whatsoever, enabled or not.
Comment #6
donquixote commentedI have no idea which branch I need to patch against. So I simply do it against master.
Comment #7
donquixote commented...
Comment #8
donquixote commentedBtw, the same is true for any other module that flushes this cache.
In particular:
- admin_menu: #1319138: "Page requisites" should also flush the page cache
- dqx_adminmenu (fixed just now in 6.x-3.x-dev)
Comment #9
moshe weitzman commentedI'm inclined to keep restrict the cache clear to just css+js just as the label says. Thats enough for development purposes which is where I would expect this to be used.
Comment #10
donquixote commentedSorry if I get emotional about this..
Drush is a great tool, and you guys have all my respect for this.
I know this is "for free", so I did do my homework and produced a patch.
But.
I just spent quite a lot of time to find out why this is happening, paranoid that something I did will break the live site when we launch the new feature. And then I see this is known since forever, and tagged as "not a bug".
Why would someone not use drush cc on production? Is there a warning somewhere? Or is there a reason to assume that "cc css+js" is less safe than "cc all" ?
Typical use case: A small CSS fix, pushed online. We want to skip a lengthy "drush cc all", so we do a simple "drush cc css+js". No reason to expect anything bad to happen.
Or, consider a site or a team with a less rigid workflow, where a lot of minor changes happen directly on production. Such as, Joe Blogger's personal Drupal site. Or, a client with direct access to the drush commandline
Or simply, we notice this behavior on a dev site, and then think that something must be terribly broken, and we have to postpone the launch of a new feature.
A "clear cache" should not be allowed to break a site - and this is what it does.
If a cache A depends on cache B, then when clearing cache B you also need to clear cache A.
Yes, I do have the page cache disabled on the dev site, but I also have CSS aggregation disabled (using unlimited_css to get around the 31 limit on IE). Someone might even flush the theme registry on every page.
One could argue, we don't need any drush cc on a development site, we simply disable all caches.
There is three situations:
1. Page cache disabled. In this case, clearing this cache along with css+js has zero cost, and zero negative effect.
2. Page cache enabled, on a dev site. In this case, a drush cc css+js without clearing this cache does break the site for anonymous - which could be the client, who wants to have a look. And the average site maintainer does not even notice. This is not visible to any end visitor, but it causes wild confusion and paranoia, because noone really knows what is going on.
3. Page cache enabled, live site. Page cache unflushed -> site unusable, angry client, etc.
I really don't see how this is even a question.
Imo, "where I would expect this to be used" is almost always going to cause trouble. This is like, you give away bottle openers for left-handed people, that will explode if you use it with the right hand.
Ok, sorry for the drama and the rumbling.
Comment #11
moshe weitzman commented@donquixote - i really appreciate all the work you do on drupal. i pray each night that we could get #653784: Separate out menu links from hook_menu. But, we disagree about how much hand holding drush should do here. there are render caches that we could clear, block caches, etc. i like your bottle opener analogy, but ultimately i am not convinced.
Comment #12
donquixote commentedThanks!
Ok.. let's for one moment assume there were two different drush commands.
One that is "drush cc css+js+page".
And the other, "drush cc css+js". This one with a warning, that in one situation it can break your site, and that it has no real benefit otherwise.
Which command would you use?
(disregarding that one of them is more to type)
I thought about this before, and came to the conclusion that page cache is the one we have to clear. Other caches can remain unflushed.
There is no performance issue about this, because either it is disabled, or we would have to clear it anyway.
Comment #13
donquixote commentedAt least, i would appreciate if you try to convince me, if I cannot convince you.
Comment #14
sydesy commentedHi,
drush cc offers:
[0] : Cancel
[1] : all
[2] : theme registry
[3] : menu
[4] : css+js
[5] : block
[6] : module list
[7] : theme list
Not sure if the "page" (or css+js+page) is a new option or a not documented one. Can you clear the page cache from cc?
I think Moshe is right saying drush cc is to be used between consenting adults, but would agree with Andreas that it needs some kind of warning that its use might have unexpected consequences.
May I offer my dumb user pov? while running drush cc, I don't know if/what combinations are safe nor if some are a superset of another. I'm assuming that "all" is including all the others (that might be a wrong assumption, eg does it clear the image thumbnails?). I don't know if 2 does 4 and/or 7 nor do I know how to clear the page cache.
Would be good to have an additional one liner "Clearing partial caches might cause errors on your site. When in doubt, clear all".
X+
Comment #15
donquixote commented> between consenting adults
I want one for children :)
> some are a superset of another
yep, some are :)
And some are missing. For instance, admin_menu can clear "cache tables", which includes the page cache. In drush cc this would be included in "all" afaik, but there is no dedicated option neither for cache tables nor for page cache (correct?).
On the other hand, admin_menu has no "block" option, no dedicated "theme list" option, etc.
Altogether, both admin menu and drush could receive a complete set of child-friendly cache clear options, if someone would sit down and do the math (which I might even do, if there is an interest).
Comment #16
wim leersI've also been waiting for a
drush cc page. I understand moshe's point of handholding. But why not offer the ability to allow developers to do it manually if they choose to do so?Reopening to get an answer to that from moshe or another drush maintainer. Feel free to close again immediately afterwards.
@donquixote: if you want to keep old aggregated CSS/JS around to not break the layout in Google's cached search results, give the AdvAgg module a try.
Comment #17
donquixote commentedIf we would have the complete dependency tree of cache clear available, we could offer variations:
drush cc [name] would clear [name] and all dependent caches.
drush ccc [name] would only clear the cache in question, leaving dependencies unchecked.
This would obviously be a new feature, and go beyond the initial request. Maybe deserves a new issue.
Comment #18
moshe weitzman commentedContrib can add new options to the cache clear list. Views does that. Dunno if varnish module does that but it should. Add one for page cache if you wish.
Comment #19
moshe weitzman commentedI mean, add it in Contrib, not drush core.
Comment #20
doublejosh commentedhttp://drupal.org/project/flush_page_cache