Split install_complete, allow redirects

So the motivation of this is to be able to have HTTP requests inbetween the "install finalization" and the "completed page", to import all translations for enabled modules as an example. You seem to solve this by either returning a message from the "hook_profile_final()", to signify that installation is ready, or redirecting to a different page in that function, and sometime later redirecting back to the "?install_final=1" page to get the "completed" page.

Some notes:

- How would some other operation work in install.php? What URL will it allow to run?
- You have some misleading references to $_SESSION['install_final'] which should be $_GET[...] I guess

I was concerned about possible problems with the live Drupal being called to do stuff, but because it seems this stage is only called when Drupal is fully built, it should not be a problem. But a custom profile message is not possible to set with this solution (which should be possible somehow).

It would be great if either Neil or Steven could comment on this.

I have put a lot of thought the last two days into whether we require this split at all. As a matter of fact, install profile developers were told to redirect from profile_final() if they needed to display wizards or do any extra processing in installation. Because it was not possible to get back to the "install complete" screen later (no URL to display that screen), people were told to present their install complete screen after that redirection on their own. This worked with Drupal 5.

Now with Drupal 6, automatic interface translation importing functionality is supposed to end up in Drupal core. So we either need (a) default.profile to support automatic importing or (b) have an alternate install profile in core which supports automatic importing. Either case, we need to run code in multiple HTTP requests (a batch) and get back to an "install complete" screen at the end. If we would ship an alternate install profile for this, a hackish redirection out of the installation process might be workable (but I doubt it will be nicely accepted into core). However, automatic translation importing seems to be something core to the system, which should be supported by all install profiles with an international target userbase, so we will surely have to build that into default.profile. Unless we can run other HTTP requests before install_complete() is called, we cannot do batch importing in the default profile. But install_main() and install_complete() runs through in one HTTP request, so the database setup and the "install complete" screen is done on the same request. It is not possible to add requests inbetween.

This patch has the value to allow more HTTP requests between the database setup and the "complete" screen, by allowing a redirection to Drupal paths and then possibly redirecting back to the stock "complete screen", or by displaying a custom install screen as before. The accessibility of the stock "install complete" screen by an URL is what is new.

Whether the solution presented is nice or not is up for review. Whether a similar solution is required for us to step ahead with automatic translation importing is evident.

I understand the use-case, but I'd still like to see this checked with Neil and/or Steven -- they did a lot of work on the installer and have a good amount of background information that we might benefit from.

Isn't the goal to build the auto-locale module into the installer? As there is already a locale step in the installer shouldn't the auto-locale code be moved into install.php? Shouldn't we simply build this into the existing state machine?

Related patch: http://drupal.org/node/141637

OK, continue on that patch. It seems to have superior solutions (adding the custom installer states concept). It might already be ready for comitting, although the concept of states are not really clear to me. meba, could you try adapting autolocale to the state concept introduced there (ie. add a state of "importing translations"). I wonder if we can keep staying in the profile (install.php on the URL) while running the importing batch, so the user can see the task list. That would be nice usability-wise.

I wonder if we can keep staying in the profile (install.php on the URL) while running the importing batch, so the user can see the task list. That would be nice usability-wise.

Yes, I tried to design the batch API so that this is possible - update.php currently works that way. See the second param ($url) for batch_process().

This is in fact possible because update.php bypasses FAPI submission workflow (which would otherwise handle batch_process itself, redirecting it to the 'regular' '/batch' processing page).

I'm not exactly sure how install.php behaves FAPI-wise, so this might need some investigation (difficult for me right now, I'm away from my coding environment)

OK, install.php does use FAPI submission workflow - looking at how update.php works, I incorrectly assumed that separate scripts (not index.php-based) could not.

This means install.php's _submit callbacks are not supposed to use batch_process, and you currently don't get the opportunity to specify a custom url for the progress bar page. I'll try to refactor batch_set / batch_process API a little bit to allow for this - will do that when I come back to my coding environment in a few days. Sorry about that.

yched, no need to look into it. We can (and should) reuse an update.php like batch workflow (we already have code which works nicely with that). The new install states in the works allow bypassing all of the installer and get control of specific steps to run batch operations. Because the admin user is already created and logged in at the time of importing, we can also neatly restrict the batch to the admin user. So everything works nicely there.

I still think it's a shame that batching in form submits does not let you specify a custom processing page. Seems like an unneeded limitation, only coming from my misconception that standalone scripts could not use the full fledged FAPI processing workflow, and had to hack their way around it like update.php does.

I'm glad to hear it does not get in the way of pre-final batches during install, but I fear there might be other cases where this bites us (and _forces_ us out of FAPI neatness into custom $_POST hacking). Or, put in another way : because of this, it seems we could currently not convert update.php to a clean FAPI workflow if we wanted to.

I perfectly understand if you prefer to keep things as they are now, though, and I will not move on this if you do not wish me to.

I just said it is not required by what we do *now*. What we would rather need is to be able to run batch API anonymously (with update.php), as posted elsewhere. That is a pressing issue to fix, or otherwise it is not possible anymore to run an update without being authenticated.

Got it. Not easy for me to test / roll patches just now, but I submitted a possible fix in the original batch thread : http://www.drupal.org/node/127539