2

I am running drush version 5.3:

rob@drupaldev:/var/www/drupal$ sudo drush version
drush version 5.3

When I attempt to execute the views-list command it says that the views module is note enabled.

rob@drupaldev:/var/www/drupal$ sudo drush views-list
Command views-list needs the following module(s) enabled to run:     [error]
views.
The drush command 'views-list' could not be executed.                [error]

However, the module is already enabled:

rob@drupaldev:/var/www/drupal$ sudo drush pm-list|grep -i views
 Chaos tool   Views content panes              Module  Not installed  7.x-1.0 
 suite        (views_content)                                                 
 Views        Views (views)                    Module  Enabled        7.x-3.3 
 Views        Views UI (views_ui)              Module  Enabled        7.x-3.3 

Any ideas what else could be causing this?

Greg suggested that it could be a permissions issue or an environment issue caused by the necessity of using sudo. After having fixed one of my permission issues, I can reliably run drush with or without sudo. In either case it returns true.

rob@drupaldev:/var/www/drupal$ sudo drush ev 'var_export(module_exists("views"));'
truerob@drupaldev:/var/www/drupal$ drush ev 'var_export(module_exists("views"));'
truerob@drupaldev:/var/www/drupal$ 
3

As Greg already mentioned in a comment, you will likely find that

drush cache-clear drush 

removes this error.

  • Or, even shorter, drush cc drush :) – geerlingguy Apr 12 '13 at 17:04
3

This is working just fine for me on a d7 site using Drush 5.4. You are getting that message because module_exists("views") is returning false. Your next example shows that views is enabled, which implies that module_exists("views") should be returning true. Perhaps your site is not always bootstrapping cleanly under Drush?

Try:

drush ev 'var_export(module_exists("views"));'

Add on the 'sudo' as you do above, if you really need it. The sudo does give me pause; I prefer to set up my permissions in such a way as to allow Drush to run without it. Sometimes sudo changes your environment subtly (e.g. your $PATH may change), although I cannot think of a reason why it would cause you trouble in this instance. In any event, if the test above returns 'true', then you've stumped me. If it returns 'false', it indicates that there is something inconsistent or incorrect about your environment. You'll have to dig deeper to find out what it is.

Edit: I'm wrong, there could be other reasons why you are getting that error, even if module_exists("views") returns 'true'. It probably boils down to drush_bootstrap_to_phase() failing when called from _drush_bootstrap_and_dispatch(); however, I can't imagine why this would fail for views-list, but work for pm-list. More data is needed.

Edit 2: Try again with Drush All-versions-5.x-dev (or check out head of master from git). This is usually the first thing I suggest, but I thought that none of this code had changed recently. Turns out that enabling / disabling a module now clears the cache, but this feature was added after Drush-5.4 went out. drush cc drush should do the trick in the interim, but you won't need to explicitly do this in the future.

  • In checking your suggestions, I found a couple of interesting things. Somehow the uid and gid for my drupal install directory were changed to a user that doesn't even exist on my system. Apparently, the first time I ran drush, I did so with sudo, because my .drush directory was owned by root. – rhuffstedtler Jul 20 '12 at 14:52
  • I updated my original question with the results of the php eval. Do you have any specific suggestions on what additional data would be helpful in diagnosis? – rhuffstedtler Jul 20 '12 at 14:58
  • Use a source-level debugger or add print statements to _drush_bootstrap_and_dispatch() (and functions deeper down in the call chain) to figure out where the bootstrap is failing. The actual symptom is that the 'views-list' command object cannot be found, but I presume that is happening due to a failed bootstrap. Drush will look for command objects, bootstrap a little further (which may add more places commands can be found -- such as inside modules) and then look for commandfiles again. – greg_1_anderson Jul 20 '12 at 16:24
  • Still curious why this works for me, but not for you. Maybe install a clean d7 site with views, and see if it works -- then add modules from your site and see if one of them breaks the views-list command? – greg_1_anderson Jul 22 '12 at 4:14
  • Maybe it is the drush command cache? I could not force drush into a state where views-list could not be found per your example, but all the same, try drush cc drush and see if that clears it up. Also try drush cc all for good measure. – greg_1_anderson Jul 22 '12 at 14:18

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.