Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#1 | 833192-1-install-order-modules.patch | 941 bytes | carlos8f |
Comments
Comment #1
carlos8f CreditAttribution: carlos8f commentedThis patch orders the modules before they are sent to the batch.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedthis 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.
Comment #3
David_Rothstein CreditAttribution: David_Rothstein commentedAwesome. 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:
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!
Comment #4
Dries CreditAttribution: Dries commentedThis looks good. Renaming the variables is not a hard requirement for me, so I proceeded with committing this patch. Thanks.
Comment #6
threexk CreditAttribution: threexk commentedAlso exists in D6. Would it be hard to backport patch? I could remove a lot of ugly hook_requirements() code from modules...
Comment #7
carlos8f CreditAttribution: carlos8f commentedI 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.
Comment #8
threexk CreditAttribution: threexk commentedDependencies 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.
Comment #9
carlos8f CreditAttribution: carlos8f commentedHandling 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.
Comment #10
grendzy CreditAttribution: grendzy commentedI 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).
Comment #11
ergonlogicThis 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...
Comment #12
aken.niels@gmail.comNot 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?