Using Drush update on a 6.13 installation - no updates were found but Drush disabled all modules because they were "incompatible"
....
module rules_scheduler is incompatible with this release of Drupal, and will be disabled. [warning]
module contemplate is incompatible with this release of Drupal, and will be disabled. [warning]
module admin_menu is incompatible with this release of Drupal, and will be disabled. [warning]
module register_modify is incompatible with this release of Drupal, and will be disabled. [warning]
module birthdays is incompatible with this release of Drupal, and will be disabled. [warning]
module rules_admin is incompatible with this release of Drupal, and will be disabled. [warning]
UPDATE {system} SET status = 0 WHERE name IN [success]
('user_import','guestbook','rules','nice_menus','front_page','email_registration','quotes','googleanalytics','privatemsg','userpoints','userpoints_rules','devel','content','content_copy','content_permissions','date','date_api','date_copy','date_php4','date_popup','date_timezone','fieldgroup','nodereference','number','optionwidgets','text','token','userreference','views','geonames','views_ui','captcha','image_captcha','recaptcha','lncampaign','openinvite','imageapi','lnmisc','lngroups','lndonate','rpm','imageapi_gd','imagecache','imagecache_ui','imagecache_profiles','ip2nation','og','og_views','imagefield','filefield','rules_scheduler','contemplate','admin_menu','register_modify','birthdays','rules_admin')

Comments

MikeMcLean’s picture

+1

I had the same problem and I know all of the modules it disabled were compatible. Not a killer, but annoying.

jonhattan’s picture

StatusFileSize
new1.75 KB
new17.41 KB

This is a weird one. Unable to reproduce by myself and seems it is not a generalized issue btw.

I've put an eye on the code and this piece is responsible of marking a module as incompatible:

  if (!isset($file)
      || !isset($file->info['core'])
      || $file->info['core'] != DRUPAL_CORE_COMPATIBILITY
      || version_compare(phpversion(), $file->info['php']) < 0) {
    return TRUE;
  }

...four possible ways for a module to be incompatible. I have changed this condition to four separate `if` statements with it's corresponding log message. Attached is a patch against cvs HEAD. If you are able to reproduce the bug again, we can guess where the problem comes from :)

ps: in case you dont know how to apply a patch, I've also attached the modified file (replace commands/core/drupal/update_6.inc with this).

rsvelko’s picture

Status: Active » Postponed (maintainer needs more info)

we need some feedback from heydemo...

heydemo’s picture

Status: Postponed (maintainer needs more info) » Active

Ok, I applied patch and re-ran - I'm getting "not found in filesystem" for all modules.

module user_import not found in filesystem! [error]
module user_import is incompatible with this release of Drupal, and will be disabled. [warning]
module guestbook not found in filesystem! [error]
module guestbook is incompatible with this release of Drupal, and will be disabled. [warning]
module rules not found in filesystem! [error]
...

I peaked into the $modules array and it looks like only core drupal modules are included, which explains why it's disabling all the contributed modules

moshe weitzman’s picture

Status: Active » Postponed (maintainer needs more info)

where are those modules located in your source tree? symlinks? permissions?

heydemo’s picture

Modules are located in /var/www/dev.lifenets.net/htdocs/sites/lifenets.net/modules

I'm running the: drush -l dev.lifenets.net update

Modules directories are set to
drwxr-xr-x 6 heydemo heydemo

Module files (.info, .module) are set to:
-rw-r--r-- 1 heydemo heydemo 178 2009-07-15 14:16 token.info

heydemo’s picture

Status: Postponed (maintainer needs more info) » Active
moshe weitzman’s picture

Status: Active » Postponed (maintainer needs more info)

Hmm. i always use the http:// when specifying -l. Could you see if that helps? Thats how it is documented in example.drushrc.php. We could be more verbose in drush help, I think.

heydemo’s picture

Status: Postponed (maintainer needs more info) » Active

Ok, I tried with http:// and it worked correctly, then repeated without http:// and it disabled all modules again, so looks like that is the reason.

jonhattan’s picture

http:// is now optional: http://drupal.org/cvs?commit=270894

so I think this issue can be closed.

heydemo’s picture

Status: Active » Closed (fixed)
greggles’s picture

Version: All-Versions-2.0 »
Status: Closed (fixed) » Active

I just got this error when upgrading a few sites. I updated my drush and still get it. I tried with http:// on the beginning or not and still get it.

If I then do "drush en comment_notify" the module enables just fine.

The module is in sites/all/modules and is readable by the webserver user.

patrick2000’s picture

Status: Active » Closed (duplicate)

Boa ... that bug is lingering around for more than half a year ... !???

Sorry - I just stumbled over this and reported:

http://drupal.org/node/762754

Will set mine as duplicate now - didn't find this one before.

patrick2000’s picture

Status: Closed (duplicate) » Needs work
patrick2000’s picture

I boiled that down a bit.

Commenting out the following line in drupal/includes/theme.inc solves the problem.

I wonder when and exactly why this was introduced. IMHO it breaks system_theme_data() in modules/system/system.module.

So I guess it's a drupal core bug.

--- ./includes/theme.inc.orig 2010-03-01 05:02:01.000000000 -0500
+++ ./includes/theme.inc 2010-04-06 03:57:36.000000000 -0400
@@ -501,7 +501,7 @@
// Status is normally retrieved from the database. Add zero values when
// read from the installation directory to prevent notices.
if (!isset($theme->status)) {
- $theme->status = 0;
+// $theme->status = 0;
}
$list[$theme->name] = $theme;
}

patrick2000’s picture

Created a Drupal Issue at http://drupal.org/node/763172

patrick2000’s picture

Drush doesn't care for that: http://drupal.org/node/763172#comment-2811728
That's why!
:-)

greg.1.anderson’s picture

You know, I have not fully investigated this issue, but I suspect your suggested fix to drupal core might be rejected, in which case we would have to fix it in drush. To have a chance of being fixed in core, you'd have to submit a patch and set the status of your issue to 'needs review'.

Could you try rolling a patch for drush that makes the call to _system_theme_data() in environment_6.inc look like the code you quoted in the other issue?

patrick2000’s picture

StatusFileSize
new1.73 KB

Sure ... drupal 7 seems to work differently ... 5 i didn't test, 6 is (tested) fixed with that one here:

greg.1.anderson’s picture

Status: Needs work » Needs review
jonhattan’s picture

Well, disabling all modules is not the same as disabling all themes :)

Drupal 5 does not implement _system_theme_data() and in general do updates in another way. I think it is not affected.

If the error only happens when updating, it seems the correct solution is to rollback those change:

* http://drupalcode.org/viewvc/drupal/contributions/modules/drush/commands...
* http://drupalcode.org/viewvc/drupal/contributions/modules/drush/commands...

I'm unable to patch now but will do it tomorrow if no one hooks.

jonhattan’s picture

From comment #13 the issue is other. I'll close this one in favor of #762754: All themes disabled after updatedb.

@greggles of you still have a problem with modules please open a new issue.

jonhattan’s picture

Status: Needs review » Closed (won't fix)
braham.p’s picture

Version: » 6.x-3.2
Component: Code » Base system (internal API)

It may be one case that these modules folder is not existed on your on server but the module has been saved with “enabled” status {status=1} in {system} DB table during deployemnt. In this case, this type of modules have been disabled {status=0} in DB via drush . Then this is not an issue and you can continue.

- Braham