Installer dosn't support modules outside root/modules directory

Good point, this is purely reltaed to directory traversal and file discover. Will move it, thanks.

Here's a slightly updated version of the code, with the helper function moved to file.inc.

Definitely. I still need to hammer out a remaining issue -- the initial installation process doesn't properly install modules in the /profiles/$profile/modules directory. It works fine once the installation is done and the user visits admin/modules.

Installing modules from the profile directory now works, and some commenting has been added to install.inc to make the various steps easier to understand. Yay!

Chatted with chx, and he agreed that since this deals specifically with theme/module/etc traversal it would make sense in common.inc. This version of the patch renames the function to drupal_system_listing() and locates it in common.inc.

Dries, after doing some further investigation, I don't think there's really any way around the need for the global in this scenerio. After the installation process is complete, we can just variable_get() to find out what profile is active - that's how system.module did it until now.

But *before* the install, when htis code runs, we don't even have database access to call variable_set(). The name of the current profile (and thus the directory name we should be scanning) is stored in the global. In an earlier version of the patch I tried passing $profile_name into the function directly, but it's called from many locations in core, most of which need to work properly in the pre-install state. Passing it around instead of using the global would require 'punching' through several layers of includes and function calls, tacking an optional param onto the end of each one, for this single special case.

Long-term, this kind of situation is what chx's http://drupal.org/node/71113 patch would help solve. We may want to look into that to avoid sprinkling 'check for a global, then check the variables' logic throughout core.

Dries commented on IRC that he'd greenlight it if there were no clean solution for the global at this point. The bulk of this patch is moving the function to common.inc; the other two changes are pretty minor.

In that light, I'm RTBC'ing.

But the first thing we do is ask the user his database information? So in theory, we should be able to setup a database connection ... not?

Nope. We're in DRUPAL_BOOTSTRAP_CONFIGURATION mode when we hit this code. Absolutely nothing is installed, we're just *ensuring that the things the profile requires* are there *to* be installed.

(If not, please add some additional code comments to the function. Much of the knowledge you shared in the issue tracker is not documented in the code. Don't overdo it, but just explain why we do it the Ugly Way.)

function drupal_system_listing($mask, $directory, $key = 'name', $min_depth = 1) {
  global $profile;
  $config = conf_path();
  
  // When this function is called during Drupal's initial installation process,
  // the name of the profile that's about to be installed is stored in the global
  // $profile variable. At all other times, the standard Drupal systems variable
  // table contains the name of the current profile, and we can call variable_get()
  // to determine what one is active.

  if (!isset($profile)) {
    $profile = variable_get('install_profile', 'default');
  }