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 '14 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 '14 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. – Alex.Barylski Oct 9 '14 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 '14 at 17:46

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 '14 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. – greg_1_anderson Oct 9 '14 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 – Alex.Barylski Oct 10 '14 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. – greg_1_anderson Oct 10 '14 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, privacy policy and cookie policy

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