I am trying to clear the cache using Drush cc all because I deleted a function in the module/theme files and the site won't render...

I always have to login in as admin, performance > Clear all caches

This works...what is the equivalent Drush command?

  • 1
    That is the equivalent drush command. It should have the same effect
    – Pere
    Oct 9, 2014 at 16:56
  • Yep that always works for me too - are you sure the deleted function isn't being explicitly called from another function? If you check your server logs it should tell you what module/include the error originates from
    – Clive
    Oct 9, 2014 at 17:00
  • Weird...I have tried and tested and it's not working as expected...I login as admin and clear cache through UI works...drush cc all...doesn't seem to flush the templates :s the deleted function is a theme hook theme_textfield in this case. I removed it...refresh page and bam no fields appear...called drush cc all and it didn't work...restored function...logged in...removed function...refreshed cache and voila the default was used as expected. Oct 9, 2014 at 17:05
  • Interesting. Any chance you're using a non-db cache that may not be being flushed correctly, or maybe an incorrect cache-bin prefix in settings.php?
    – Clive
    Oct 9, 2014 at 17:46

2 Answers 2


I did not try to reproduce your exact situation, but some operations called by cache_clear_all write / remove files from the filesystem. If your filesystem permissions are not correct, then drush cc all will do all of the database clearing just fine, but will leave the other operations undone.

There are two potential solutions to this:

  1. sudo -u www-data drush cc all

Some folks don't like to use 'sudo' with 'drush', but if you run Drush as the webserver user, the cache-clear should work.

  1. set the permissions of your webserver files so that the user that you run Drush as can read/write to the filesystem.

I usually make my webserver files owned by a 'www-admin' user in production, and I make them owned by the user I log in as on my development system. I set the group of all files to www-data, and make those that the webserver needs to write to group-writable. This works pretty well for Drush + Drupal access on Drupal 7.

  • I think the OP is experiencing something slightly different (might be wrong) - from the last comment on the question it sounds like the theme registry isn't being re-built, I'm not sure file permissions could affect that directly. Or could they?
    – Clive
    Oct 9, 2014 at 17:45
  • Seems to have something to do with the filesystem from the symptoms, so I'd try that first. Stepping through the cache-clear op would be the next step, but fairly labor-instensive. Oct 9, 2014 at 18:43
  • I was executing drush as root in this case so it can't be a file permissions issue...I was thinking (didn't occur to me earlier) that Drush has no way of knowing which site I want to flush so I assume I have to invoke Drush from with the /drupal/sites/www.something.com/ directory in order for it to know which database, etc to even flush??? It doesn't error though which I thought was weird Oct 10, 2014 at 2:14
  • 1
    cd to the folder that contains settings.php to select the Drupal site to operate on, or specify via --root and --uri. drush cc drush will say that the Drush cache was cleared if no Drupal site is selected. Oct 10, 2014 at 2:27

I was invoking drush from any location I was currently in...when I cd'ed into the sites folders accordingly it seems to work. Not sure how I missed that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.