site-install command doesn't complete installation batch process

I can confirm this on drush-4.4 and it is true that it completes other install profile tasks but seems to ignore the
_profile_modules() function.

Or possibly not. It seems to enable some of the modules listed, but not all. It doesn't appear to be individual modules, I can usually get different combinations by altering the order listed in the array returned in profilename_profile_modules()

It doesn't seem to be a specific number of items either, sometimes it seems to be 2 or 3 modules, sometimes it appears to be 5 or 6 that actually do get enabled.

And it does enable all of them when running the profile install process via the UI.

From the install.php file (~line 672)

  // We are running a batch install of the profile's modules.
  // This might run in multiple HTTP requests, constantly redirecting
  // to the same address, until the batch finished callback is invoked
  // and the task advances to 'locale-initial-import'.

I wonder if the drush site-install call for installation:

  $phpcode = _drush_site_install6_cookies($profile, $cli_cookie). ' $_GET["op"]="do_nojs"; include("'. $drupal_root .'/install.php");';
  drush_shell_exec('php -r %s', $phpcode);

which happens between op=start and op=finish is not letting the batch complete correctly before it continues on to op=finish.

Not sure how to fix this without the ajax continuous refreshing. Maybe to put it into a loop until the task can be identified to 'locale-inital-import'?

EDIT: Actually, we need to loop until the batch success setting is TRUE. Because we're manually calling the "finished" batch step.

Drush site-install calls the install.php page manually three times, once each for "op=start", "op=do_nojs" and "op=finished", but the "op=do_nojs" phase possibly needs to be called multiple times. The web UI installer does this with $batch['progressive'] being set to true, but drush site-install can't change this to FALSE (which would cause the whole batch to be processed in one step).

So I wrote a patch that will bootstrap the database and just periodically check the batch process to see if the batch success variable has been set.

So in talking w/Moshe last night, we also ran into the issue that bigger install profiles like OA or Commons also have multiple tasks that run after the configuration screen and in fact may alter the configuration screen as Commons does. So while this patch doesn't get you all the way there to be able to install a "full fledged" profile like OA, I still think that it is needed for the part of site-install that drush does currently handle for D6.

Allowing other configuration options may be out of the scope of this issue specifically and deserve its own issue. Aegir handles this through the provision module, but if we're not going to script this part out in site-install, I still think the patch above does what it's supposed to to fix a particular problem.

I'm fine with dealing with post-configure tasks in a new issue. Perhaps you can elaborate on what provision-install does.

I'll review and commit this one soon.

I spent an hour wondering why my install profile was mysteriously not initializing correctly until I realized it was only broken with site-install, & worked in the browser. :( #4 fixed it. :) Committed to master.

Thanks ... We added ability to pass info to post-configure tasks (for D7) so site-install is in pretty good shape now for custom profiles. See #1198956: Site Install: allow passing additional form parameters

If there is an error in the install profile, now site-install will fall into an infinite loop, with the result page saying:

The installation has encountered an error. Please continue to <a href="...op=finished">the error page</a>

Need a good way to detect the error and exit, ideally w/out scraping the output. Looking at it.

The site install process signals that the do_nojs stage should be repeated via a refresh tag:

<meta http-equiv="Refresh" content="0; URL=http://default/install.php?locale=en&profile=wk_profile6&id=1&op=do_nojs">

It might be okay to search the output for such a refresh tag as an indicator that the loop should consider. As an alternative, jonhattan's technique from #1186480: Make the batch api benefit of backend show progress automatically. might be of help here.

Monitoring the install process with a fancy version of ArrayObject does not work here. Checking for the refresh meta tag gets good results, though.

Edit: Posted the wrong thing, one moment...

Detection of a failed site install is a little tricky. In the end, I found that the install_task variable was the most reliable way to go; I was not getting good results from the batch table. Although checking for install_task == "configure" is by no means guaranteed to continue to work in the future, I am guessing that d6 is at a point in its life-cycle where it is unlikely that the way installation works will substantially change.

Here is a better version that checks to see if the install_task changes during the batch process. The install task must make some progress (change values); if it does not, it signals that the installation has failed (exception: the "finished" stage does not advance the install task). This should be more stable than the patch above, and it also produces a better error message on failure (a broken install profile produces an error message with the word 'profile' in it).

is there a profile that we should test this with?

Fixes my install of http://drupal.org/project/drupalorg_testing so committed to master - a31b680dd1d7b98a54eaca6204c34629f9a3a114

Can't think of any reason not to backport, but have not tested.

All your links are nofollow, asshole. May you burn in hell

All your links are belong to us? #16 must have been pretty choice. #13 should be fine to backport.

Looks fine to me.

Backported to 4.x.