This is very handy for testing node access modules, as well as in site upgrade scripting. Adding it to the clear cache command is a single line patch, however I am wondering if this will be to inconvenient to people with large sites, since "cc all" could run for a long time, and they would then need cal call the other $types with separate drush cc calls. One way to ameliorate this would be to allow multiple types in a single command, which should be a simple explode and foreach loop. On the other hand, moving this to a new command seems a bit heavyweight.
Thoughs?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | node_access.patch | 638 bytes | owen barton |
| node_access.patch | 639 bytes | owen barton |
Comments
Comment #1
owen barton commentedOh wait - I misread "all" as iterating over all our defined $types, however it just calls drupal_flush_all_caches, which does not rebuild node access. Hence, I don't see a downside here - unless anyone has any feedback I think I will go ahead and commit later this week.
Comment #2
greg.1.anderson commentedHow about "cc quick" as a shortcut for all of the caches except those that would be very slow to clear and rebuild?
Comment #3
owen barton commentedAnd of course, we can't have a space here
Comment #4
moshe weitzman commentedFor me, this is needs work because of what you said - makes 'all' useless on large sites with node access. We might be getting to a point where we need to mimic 'structure-tables-key' in the sql commands. with this key, admins can create groupings of cache commands. i don't know how many people will use this though.
Comment #5
owen barton commentedWell, as I said in #1 - it actually doesn't make "all" useless for big site because it is not actually included in "all" (without additional work). The corollary of course is that this makes "all" inaccurate, so I think there is a need for a more flexible setup if people feel it would be useful.
Comment #6
moshe weitzman commentedOK, back to CNR
Comment #7
moshe weitzman commentedCommitted this with one wrinkle - the nodeaccess option only shows up if - module_implements('node_grants')) is non empty. This matches core behavior.
Comment #9
omega8cc commentedIt looks like rebuilding node access on drush cc breaks stuff if you are not running drush as uid=1 - see #1075002: nodeaccess table compromised after site verify ( migration )
Comment #10
greg.1.anderson commentedHm, should we just force --user=1 for cc, or warn iff nodeaccess is enabled? Seems former is better, perhaps?
Comment #11
moshe weitzman commentedThat must be a special problem with nodeaccess module then. It should not be checking the current user. It should typically use node author. Please reopen with detail if I am wrong.