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.
Problem/Motivation
An oddity I just ran into with D7:
- New installation of Drupal 7.7 core + many contrib modules
- Rules (7.x-2.0-rc1) was downloaded.
- Entities API was not downloaded.
- Rules was listed as a dependency on the install profile, Entities API was not. Note: Entities API is a dependency for Rules.
- The install ran fine, it installed all of the other modules & no errors showed up, except that once it tried to bring up install.php?op=finished the Rules module gave an error that one of the Entities API classes could not be loaded, i.e. it wanted the Entities API module but it had not checked for its existence.
Some related issues:
- #820054: Add support for recommends[] and fix install profile dependency special casing
- #1093420: Recursive module dependencies of installation profile are not enabled in DrupalWebTestCase::setUp
Related search terms:
- Recursive dependencies
- Nested dependencies
Proposed resolution
The patch proposed in #9, although it is sort of hacky.
Remaining tasks
Reroll the proposed patch.
Comments
Comment #1
webchickFixing tag.
Comment #2
Xen CreditAttribution: Xen commentedsubscribe
Comment #3
PanchoNote that Panopoly Core tries to fill this gap:
panopoly_core_install_load_profile() at least includes second level dependencies (nominal, without required versions).
A core patch should probably be more complete going deeper and respecting required versions.
Comment #4
hefox CreditAttribution: hefox commentedI played with this a bit in 7 due to the simpletest issue #1093420: Recursive module dependencies of installation profile are not enabled in DrupalWebTestCase::setUp. The code for rearranging based on dependency is there in module_enable, so it'd be nice to module_enable and install_profile_info shared a helper function. However, module_enable exists out if a dependency is missing from filesystem and doesn't care about enabled modules, so that will need to be handled. Also, required modules need to be first still as they are never listed as dependency but items do depend on them. (Currently if you give module_enable a list that includes required modules and tell it to include dependencies, it rearranges the required to be after non-required sometimes)
Comment #5
hefox CreditAttribution: hefox commentedFirst stab, creates a function for both module_enable and install_profile_info to use
Comment #7
hefox CreditAttribution: hefox commentedDuring install, cannot use system_rebuild_module_data unlike module_enable, however can use some of it's internal functions to get the same data.. hacky, and reallly don't think that's the correct way to tell it's install time.
Comment #9
hefox CreditAttribution: hefox commentedI guess I could remove that debugging trigger_error....
Comment #10
joachim CreditAttribution: joachim commentedChanging the title, as this doesn't just affect install profiles.
If you write a test, and give setUp() a list of module, you'd think that ALL the dependencies get enabled, no? Wrong!
Needs a summary update, but I have crashing tests to fix :(
Comment #11
jhedstromComment #12
areke CreditAttribution: areke commentedComment #13
areke CreditAttribution: areke commentedComment #14
ankitgarg CreditAttribution: ankitgarg commentedRerolled
Comment #16
ravi.khetri CreditAttribution: ravi.khetri commentedRerolled.
Comment #20
Sivaji_Ganesh_Jojodae CreditAttribution: Sivaji_Ganesh_Jojodae commentedComment #21
jhedstromThe patch in #16 is throwing fatal errors.
Comment #22
vadym.kononenko CreditAttribution: vadym.kononenko commentedI've found simple solution to enable even newly added dependencies to already enabled modules. Verified on D7.
We need to:
1. Remove module removal condition to its dependencies could be processed.
2. After dependencies verification loop create another loop and put those removal code there. In this case we avoid dependency loop for already enabled modules.
Just see to my patch for D7 and re-roll it to D8.
Comment #23
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedMarked #2498317: Verify dependencies of the dependencies of installation profile. as a duplicate.
I'm changing the issue title here too - module_enable() itself works fine; the extra issue identified in #10 is for tests only (see also #1093420: Recursive module dependencies of installation profile are not enabled in DrupalWebTestCase::setUp which is postponed on this one - and says that that part is a Drupal 7 issue only, which it may be).
Comment #24
lachezar.valchev CreditAttribution: lachezar.valchev commentedHi,
Forgot the file. Added it in the comment below.
Regards,
Lachezar
Comment #25
lachezar.valchev CreditAttribution: lachezar.valchev at FFW commentedHi,
I am adding my proposal for patch related to #2498317: Verify dependencies of the dependencies of installation profile. that will allow check of the dependencies not only on the profile, but also the dependencies of the profile dependencies.
Thus, if there are missing modules they will be detected as early as possible.
The patch is for D7.
Regards,
Lachezar
Comment #31
KingdutchTests indicate that #9 had a working patch. From what I can see, the rerolls were faulty and removed (the method is gone from the patch and I can't find it in the Drupal core codebase) at least the
module_order_by_dependencies
method which is what's now causing the errors.I'm hiding the two (in my eyes) faulty rerolls and marking this for a new reroll which I'll attempt to do this week.
Comment #33
vacho CreditAttribution: vacho at Skilld commentedIf this issues is for backport from D8 to D7
Why?
Version: 8.6.x-dev
Comment #40
luke.stewart CreditAttribution: luke.stewart commentedLooking at this:
This issue dates back to D7 and is flagged with needs backport - but in this stage of D7 lifecycle I think this can be removed as this bug relates to new installs - and one would hope new installs of D7 are extremely rare at this point!
1093420 is an attempt to address the impacts of this bug when testing based on install profiles this seems to indicate this is still a problem - but only in D7 - there is no evidence for D8+
Reading back over the issue
I'm flagging this as needs manual testing. As I don't see any evidence suggesting that this is an issue in D9/10/11. If it is we definitely should address. But the implementation has changed somewhat and based on the comments of the method in D11 branch I'm not convinced this is still a problem.
Comment #41
KingdutchI did not get to it in the fatal week of 2018, nor in any week since: unassigning.