The installer installs modules in no particular order, i.e. not ordered by dependencies. If module X depends on module Y but module X is defined first in $profile.info, module X will be installed first. The installer already has access to the dependency order via system_rebuild_module_data() "sort" property, so it's trivial to create the correct order from that.

CommentFileSizeAuthor
#1 833192-1-install-order-modules.patch941 bytescarlos8f
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

carlos8f’s picture

Status: Active » Needs review
FileSize
941 bytes

This patch orders the modules before they are sent to the batch.

Anonymous’s picture

Priority: Normal » Critical
Status: Needs review » Reviewed & tested by the community

this patch works for me, and installs fine with after patching core with the code i pointed to here (which puts modules in the wrong order):

http://drupal.org/node/651086#comment-3129592

simple patch, RTBC. critical IMHO.

David_Rothstein’s picture

Awesome. I had noticed this bug at one point but always assumed someone had already filed it somewhere and that it would take a lot of code to solve... glad to see that is wrong :)

My only minor comment is that I stumbled over the code for a second while reading it because it overwrites the $modules variable a couple different times for a couple different purposes. It might be a little cleaner to use a separate variable, something like this:

  $module_weights = array();
  foreach ($modules as $module) {
    $module_weights[$module] = $files[$module]->sort;
  }
  arsort($module_weights);
  $modules = array_keys($module_weights);

But everything about the approach looks fine. I guess an effect of this patch is that the order in which modules are listed in the profile .info file no longer has any relationship to the order in which they are installed. I don't think that's a bad thing; just might take a little getting used to after thinking for a while that you have to write down the modules in the order you want them to be enabled!

Dries’s picture

Status: Reviewed & tested by the community » Fixed

This looks good. Renaming the variables is not a hard requirement for me, so I proceeded with committing this patch. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

threexk’s picture

Version: 7.x-dev » 6.x-dev
Status: Closed (fixed) » Active

Also exists in D6. Would it be hard to backport patch? I could remove a lot of ugly hook_requirements() code from modules...

carlos8f’s picture

Version: 6.x-dev » 7.x-dev
Status: Active » Closed (fixed)

I don't think this is really an issue for D6. In D7 we're overhauling profiles to use .info files, and order-insensitivity is a natural trait of .info files. This would be a feature request for D6, and D6 is feature-frozen anyway.

threexk’s picture

Dependencies aren't fully installed before the module that depends on them in D6, i.e., the module install order is incorrect. This causes WSoDs for the dependent module if it calls functions made available by its dependencies (see http://drupal.org/node/365098). I think it is reasonable to view this as a bug: D6 attempts to handle dependencies but causes errors when doing so. (It can't be a feature request, because handling dependencies already exists as a feature of the D6 installation system--it just isn't working properly.) The changes in this issue fix the module-dependency installation-order problems in D7; hopeful we can backport them to fix the bug in D6 as well.

carlos8f’s picture

Handling dependencies exists for D6, just not for install profiles. As far as I know, it's always been necessary to specify all dependencies with the correct order in hook_profile_modules(). Existing D6 profiles already take that into account. If they didn't, they would probably WSOD every time :) It would be *nice* if D6 was more dependency-aware, but I don't think it's a bug.

grendzy’s picture

Version: 7.x-dev » 6.x-dev
Priority: Critical » Normal
Status: Closed (fixed) » Patch (to be ported)

I think this is a bug - it causes deadlocks like #655896: Bug in dependency locking on /admin/build/modules.

If a module's hook_requirements fails, it's dependents are installed anyway, and then you can't enable the parent even after fixing whatever failure there was, because the checkbox is disabled. It also makes it really damned hard to create versioned dependencies in hook_requirements (look at panels_requirements_install() for an example of the mess this bug creates).

ergonlogic’s picture

This is still a problem, as of Drupal 6.26. Also, apart from this issue, it doesn't appear to be documented anywhere, e.g.: http://api.drupal.org/api/drupal/developer%21example.profile/function/ex...
http://api.drupal.org/api/drupal/profiles%21default%21default.profile/fu...

aken.niels@gmail.com’s picture

Issue summary: View changes

Not entirely sure, but we seem to be having the same problems here. The order of dependencies are sporadic which causes a (very rare) WSOD. Has this ever been ported to D7?

Status: Patch (to be ported) » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.