Recursive module dependencies of installation profile are not enabled in DrupalWebTestCase::setUp

#1057412: Testing of modules in profile has been marked as duplicate.

We need to remove the FALSE in

     // Install the modules specified by the testing profile.
     module_enable($profile_details['dependencies'], FALSE);

Closely related: #1215104: Use the non-interactive installer in WebTestBase::setUp()

This is a related issue for the actual installation profile process: #1253774: Dependencies of dependencies are ignored by installation profiles (and by test setUp methods)

subscribe

The patch from #3 does not work for me. The call to resetAll() in setUp() suddenly fails with a PDOException:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'klausi.simpletest780790node_type' doesn't exist: SELECT nt.* FROM {node_type} nt ORDER BY nt.type ASC; Array ( ) in _node_types_build() (line 704 of modules/node/node.module).

Workaround: create a link in sites/all/modules pointing to your installation profile module folder. Drupal has no problem with duplicate modules appearing in the file system.

Since #1215104: Use the non-interactive installer in WebTestBase::setUp() is committed this doesn't apply to D8 anymore. Changing to D7 and re rolling the patch for D7.

Hm. I wonder whether we should mark this postponed on #1253774: Dependencies of dependencies are ignored by installation profiles (and by test setUp methods) then?

Otherwise, we'd introduce a difference in behavior between how DrupalWebTestCase installs a profile and how the installer installs it?

The OP here merely seems to complain about "extra work" for install profile developers.

#1253774, however, complains about a user-facing fatal error that doesn't seem to be caught by tests.

Note that I did not verify any of these two bug reports. Somehow I have the impression that one of the reports must be bogus... Anyway, manual testing should be easy, just comment out a dependency of a dependency in standard.info (e.g., options module).

Agree, seems like fixing the other should fix this.

Encountering it also :<

Required modules are not listed as dependencies to modules
May need

    module_enable(drupal_required_modules(), FALSE);
    module_enable($profile_details['dependencies']);

(Needs work based on how required modules can be re-arranged to be after non-required in first patch)

Just adding here to not loose/may be useful (not sure if pursuing further).

Builds dependencies

Another issue is children profiles don't inherent dependencies of profile they're based on, not sure if bug or not.

Agree with sun and hefox #11 that this should be postponed on #1253774: Dependencies of dependencies are ignored by installation profiles (and by test setUp methods), because:
1. that's the real issue and
2. simpletest should be 1:1, not smarter than the Drupal installer

Will set this back to postponed right as soon as testbot finishes (yI could run it locally, but my computer's fan doesn't like that). Equivalent d8 patch failed last night, but it looks due something d8 specific so curious how the d7 version fairs, and since this issue exists and is set to 7 and this patch actually should fix the this bug also... well, curious if it'll pass.

Hm, there's a "needs backport to D7" tag on this issue, odd.

Interesting

#16: 1093420-2.patch queued for re-testing.

Need to update that with the changes with $install_state from #1253774: Dependencies of dependencies are ignored by installation profiles (and by test setUp methods)

Hmm, not really. MAINTENANCE_MODE seems to work fine.

The problem seems to be somewhere else:
_system_rebuild_module_data() invokes hook_system_info_alter().
Now, user_system_info_alter() does a db_table_exists('profile_field') to determine whether to unhide the legacy profile.module.
But if called that early in install time, there's not yet a database and not even a database.inc.

We could solve that differently but I think the error lies in user_system_info_alter() assuming that there is already a database.

Patch passed the tests.
Postponing this one again on #1253774: Dependencies of dependencies are ignored by installation profiles (and by test setUp methods)

I am also seeing the problem described in #22

Very old post I know, but I'm running install profiles using profiler and am having this exact problem which is causing my builds to fail with:

PHP Fatal error: Call to undefined function db_table_exists() in /var/.../build_201501151315_9/modules/user/user.module on line 4026

In this instance, we're talking about a brand new site where there would be absolutely no need to enable the legacy profile module, right?

So couldn't we use the fact that db_table_exists isn't available yet as part of the test?

This particular patch does nothing for the actual problem in this issue, but stops this code being a problem for people building from profiles.

---edit: I moved this patch to https://www.drupal.org/node/2412003 because it really doesn;t belong on this issue.---

#25 and #23 have conflicting patches.

Updated for 7.39

#27 is not a re-roll of #25 and doesn't work for me where as #25 does.

We've had #22 in our system for quite some time now without issue, but have recently encountered one: it's not 100% compatible with PHP 7.2. I get this during site installs:

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in module_build_dependencies() (line 1342 of includes/install.inc).

Attached is a stab at trying to combine #22 with #27, clean it up a bit (coding standards), and then rework it for PHP 7.2+.

Due to time constraints, I've tried to preserve the overall approach from #22, with the caveat that the approach does not seem very intuitive. Generally, it is a bad idea for a loop to be iterating over the same array it is modifying. Someone with more time to debug this (e.g. possibly me in the future) could take the time to step through the whole algorithm to understand it and re-write it as a more straightforward dependency graph ordering algorithm.

For this reason, I'm providing the patch so others can use it, but flagging this as NW since it's not ready IMO.

Ok... ignore the last patch. I actually did have to spend the time to understand how this all worked because the previous stab at it just caused an infinite loop. I do not understand why, but putting next($module_list) at the end of the loop seemingly had no effect. I presume it has something to do with the modifications that the loop is making in-place to $module_list, since it can affect the pointer. I also learned that the original patch (down to the comments) looks like it was based on Core's implementation of module_enable().

Regardless, I've implemented a redux version of the patch that is cleaner and works with PHP 7.2+. I also removed the optional $include_enabled parameter because I can think of no reason why this would ever get used, and $module_data[$module]->status wasn't set at all (i.e. the field is completely missing) in the manual testing that I did.

Minor header comment clean-up.

#32 is failing?

OpenAtrium is currently using #22 which is incompatible with latest PHP versions. Here is a simple update to #22, replacing `each` with `foreach`. Just so I don't have to manually patch OA every time I update it.