Provide a site config form at the end of install to collect data, plus allow profiles to modify and add more.

Fantastic! I'm assuming things like the default time zone could even go in there. Nearly infinite possibilities.

+1 on this.

Nice usability change.

Tested it, works as advertised. Setting to RTBC.

Very small nitpick:

Currently the patch has this section:

+function default_profile_final_form() {
+  // This is necessary to add the state to the $_GET args so the install
+  // system will know that it is done and we've taken over.
+  $form['#action'] = 'install.php?profile=default&state=profile_info';
+  $form['intro'] = array(
+    '#value' => t('Now, please provide some basic information for your site, so that we may finalize this information.'),
+  );

I'm guessing, but the string beginning with now finalize should perhaps end with the word installation instead of information.

As an even smaller nitpick, it may be possible to word that string in such a way that it avoids personification, like "To finalize site installation, please configure the following settings."

+1 - getting clean URLs and timezones set automatically during installation has been on my todo list for a while, and this separate phase will help out.

Including a link to do the manual clean URLs check would probably be bad, since there are other form items, but you could use the automatic jQuery version.

Okay here is a version with the jQuery clean URLs check embedded (but hidden if js is disabled). I also have it set the timezone select to the user's current timezone.

Oops, I forgot to have it actually save the clean URL setting. I fixed that and also removed the unneeded changes to cleanURLsSettingsCheck().

Updated patch which fixes the '@settings' link in the help text.
Applies cleanly against HEAD and worked for me without any problems..

Could not think of any usability issues or how we could make this easier for users. It's good the way it is now..

Please review and commit..

Great! I encourage you to check out http://drupal.org/node/126143 and to watch at the "Creating the first account" video. It might be a good source for (additional) inspiration. ;-)

One question: how does this relate to http://drupal.org/node/141479? Gabor and meba are working on that to make auto-locale imports work.

Direct link to the video: http://video.google.com/videoplay?docid=4593455544834582557

Also, the default installation instructions ("create first user account" as shown on the initial main page) might need to be updated too?

This patch is surely connected to http://drupal.org/node/141479 ... There we introduces a possibility to redirect to any page in the install process, and redirect back to the "completed page" once done. This patch introduces an "installer state" concept manifested in $_GET['state']. As far as I see, it will be possible to add any number of more tasks to the installer with hook_profile_tasks(). This might change the installer in the way we require with that patch, but is more user friendly in that the user can see the tasks ahead, while our patch simply drove out the user from the installer tasks and return her back when ready with additional tasks.

But I don't see how $_GET['state'] actually get used to invoke a function registered for that state. Or is it a misunderstanding on my part that hook_profile_tasks() is basically a bare bones hook_menu() to add more tasks?

I like this idea, but that form seems to be little bit complicated. I suggest renaming "name" to "site name" and removing default time zone - if we incorporate autolocale, it could be on it to configure time zone automatically (Gabor, do you have idea how? I mean automatically, from .po file? :)

Time zone is not related to language, so this is not something we would get from a .po file. The same language is spoken around the world in multiple countries.

1. Please don't use 'admin' in the UI. Write 'administrator'.

2. 'Admin E-mail address' should be '... e-mail address' with a small 'e'.

3. On the video, they were confused about the 'Timezone' setting. It might be good to rename this to 'Time' and/or to extend the description a bit.

4. What happens when the specified username or e-mail address is not valid?

5. Can we add some more code comments? For example, the user_load(1) check is crucial for security, yet, this isn't properly documented in the code. I'd add some comments to prevent us removing that check in future. Similarly, it would probably a good idea to describe the state machine a bit.

Other than this, this patch looks good. Especially if http://drupal.org/node/141479 can be integrated into this.

Thanks Merlin et al! :)

I've been thinking about this some more and I'd like to see us discuss the following point before this gets committed: if we want to improve Drupal's usability, this might be something that we want all install profiles to do. In other words, shouldn't this be part of the default installer rather than the default install profile? I'm bringing this up, because I'd rather not see this code duplicated in each install profile. Food for thought, but not unimportant with regard to the potential reach/impact of this patch.

holy crap, this is exciting...

Installation profiles can now have their own forms in hook_installation_finalize. There is only one slight quirk, which is that they *must* declare #submit in their form. If this is unwanted, I can have the #submit handling code automatically.

I might as well implement ^^ :)

merlinofchaos said on IRC that the form should run through profilename_form_alter. Here is the patch

Some sites/default/settings.php cruft.

Sorry.
Also, I forgot about the re-ordering of parameters of hook_form_alter. Here is an improved version.

Settings.php cruft and minor code style.

Giving the form weights, so install profiles can more easily add fields in between other fields.

and nothing is complete without a patch :)

Holy effing crap is this cool!! Site name, e-mail, administrator info, site timezone and clean URLs.. all the essentials, already setup before you even get to the front page. Awesome.

This is a small re-roll that:
* uses cvs diff -up instead of whatever crazy way that dmitri was using to do diffs. ;)
* adds a note in CHANGELOG.txt
* Re-words the initial drupal_set_message to remove the note about setting site e-mail address since that's already done.
* Removes "Create administrator account" from the list of todos on the default front page. This has confused many a person, so I'm so glad to be rid of this now.

I didn't mark RTBC because I haven't tested the programmatic method of extending the form yet (and might not get a chance to, so someone should get on that ;)).

sub

Hm. Not sure why this was marked CNW.

* It would probably be a good idea to group the settings with fieldsets? Maybe 'Site information', 'Administrator user' and 'Server settings'? If we had fieldsets, we'd be able to shorten some of the form labels -- we can probably get rid of the 'Administrator' in 'Administrator username' and 'Administrator e-mail address'.

* The e-mail validation does not seem to work. The form accepts an invalid e-mail address?

* The password field is not marked as required (although it is required). Looks like we aren't using the form APIs built-in requirement-checking for that?

* 'Enter site details' does not seems to fit the other tasks in the list. I'd simply call it 'Site settings' or something. It's the 'Enter' which is a bit weird.

* The text 'To finalize installation, please configure the following information.' shows up in the middle of the page. That looks awkward.

(For those who care; take a look at the new Joomla 1.5 installer. Screenshots at http://joomla15.blogspot.com/search/label/installer. Personally, I like their 'Finish' step. It gives me a slightly better indication of the 'end'.)

I looked at the code too, and have no outstanding comments. Gabor and Jacob (auto-locale import) promised to have a closer look at this patch's code as well. If Gabor and/or Jacob give this patch their blessing, and if we add some final polish (and bugfixing) to the new 'settings screen', it should be RTBC. Good job.

* In the 'Administrator user' fieldset, I'd add some documentation a la: "The administrator user, or user #1, automatically has all administration rights." -- or something a little more helpful. I think it's important to educate people about this user, as they are not likely to read about this elsewhere in the in-site documentation!

Humm, I just tried applying this and then installing it. I was redirected to install.php but then firefox gave me the following error:

The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

    *   This problem can sometimes be caused by disabling or refusing to accept
          cookies.

There is a bug in that prevents password fields from being marked as required - the fix is waiting to be committed in http://drupal.org/node/136067

well i tried installing a clean HEAD download and it work with no problems. re-applied the patch and got the same result. for reference i'm using Apache 2.2 + PHP5 on Windows.

Hm. I'm getting that too, now. I think it was the default.settings.php patch.

Well, I got it to quit doing that endless loop thing (it was checking global $db_url), but now the installer never finishes. :( I was able to implement all of Dries's usability suggestions, however, so once dmitri or merlin takes a look at this, hopefully they can fix it. :)

Same patch as #47, with a slightly tweaked user-facing message:

To finalize installation, please configure the following information. changed to To finalize installation, please provide the following information.

If 'configure' is a better verb than 'provide', then it seems as if it should be 'configure...settings', as I'm not sure 'configure...information' is as clear.

...and the obligatory "I forgot to include the patch file" comment.

I think a few improvements could be made to reduce the amount of extra text for the user to read and keep the page concise:

• [Site name] "The name of this website." -> unnecessary
• "The administrator account will have complete access to the site; it will automatically be granted all permissions and can perform any administrative activity. This account will be the only account that can perform certain activities, so keep its credentials safe." -> "The administrator account has complete access to the site; it will automatically be granted all permissions and can perform any administrative activity. This will be the only account that can perform certain activities, so keep its credentials safe."
• [Username] "Your administrator username; punctuation is not allowed except for periods, hyphens, and underscores." -> "Spaces are allowed; punctuation is not allowed except for periods, hyphens, and underscores."
• [Password] "Provide a password for the administrator account in both fields." -> unnecessary
• [Administrator email] "A valid e-mail address. All e-mails from the system will be sent to this address. The e-mail address is not made public and will only be used if you wish to receive a new password or wish to receive certain news or notifications by e-mail." -> remove first sentence
• [Timezone] "Select the default site time zone. By default, dates in this site will be displayed in the chosen time zone." -> remove first sentence

Also, I think the extra descriptive text for the administrator account looks strange at that placement and font size. I think it looks better at the top of the fieldset and with class="description." The translatable string should have the paragraph tags pulled out.

Finally, I think the title should be changed to "Configure site" to match the task list.

These are all arguable string changes and perhaps some shouldn't be made, but since I already tested them I'm including an updated patch too.

Tested patch 19, and it worked quite nicely. I would also remark that the password fields are not mandatory by the looks of the UI as it seems, which is being worked on already in a separate patch (for password fields in general). I would also repeat that the placement and font size of the administrator account description seems to be odd. I would put it at the top of the fieldset.

I tried to enter invalid data, and it does pass validation. The 'a!' value (without quotes) for site email address, admin username and admin email address all worked without a warning. I just noticed that even the admin/settings/site-information page allows setting of arbitrary values for the email address. Bad. But I cannot create a new user account with 'aa!' username and password, so we have code to reuse here. :)

Otherwise this is a very exciting development for Drupal!

Boy I'm coming in late to this one... I like the idea in concept, but with the form living in core rather than in each profile will it be possible for an install profile to pre-load and skip some or all of these? We currently have an install profile that sets most of our configuration for us, including a macro to create the first user, since 95% of our clients are in the same city. (uid 1 has the same name, time zone is always the same, enable clean URLs since our dev server works with it, etc.) If there's some way that an install profile can have less of a form than normal instead of more, I'm happy. :-)

Tested once more, and this looks ready to go. I'm still leaving it CNR because of Crell's comments and because I don't know what (if any) testing has been done on the programmatic side of things. If someone could post a foo.profile that we could test with, that'd be awesome.

@Crell: profiles are allowed to have a profilename_form_alter to alter the form.

A form_alter is just dandy. I just wanted to confirm we would have that option. Spiffy!

1. Dries already suggested above that the "Finished" step should be visible in the list, just like in the screenshots he linked to of Joomla 1.5.
2. st() and t() are used intermixed in the form. Because install time strings have the tradition of being st()-ed, instead of t()-ed (we don't have translations imported yet), that should be used here. Unless we will have the automatic translation import before this form is displayed, which seems to be unlikely.

I will try to come up with a use case for additional states with our automatic locale import works (although that will also be integrated, but will need to be built into the same framework anyway).

I also noticed that if you have more languages available for the installer, there is no step indicator on the left side added for selecting languages (and none of the steps is indicated to be active when the language selection takes place). Test with adding files with zero bytes named it.po, de.po, hu.po and so on into the default profile directory.

OK, went on to do a test install profile with states. It was not entirely clear at the start, so some things will need documentation for sure. When it first comes to running my profile_final() the state is 'finalize', then I am supposed to either return something to display or not depending on whether I am ready. But the state machine is really not dependent on what I return there. A separate hook is used to define states.

I don't really understand what value you see in having separate funcitons for profile_final() and profile_final_task(), especially that the later is called just after the former, there is nothing happening inbetween. Why would't I put the logic from profile_final_task() to the end of profile_final()? My use case required making decisions of the profile state machine implemented in profile_final() to either keep the current state or advance to the next. Now I would have been able to find a way to come up with some information sharing between the final and the final_task function, I figured I'd rather variable_set('install_state') myself. So my final_task function ended up variable_get()-ing only. I don't see the use of this function. IMHO we can simplify the API by either asking profile_final() to set the variable or pass the $state by reference and get the modified state from there. Also note that the output returned from profile_final() is discarded when the $state gets to be "complete", and a different function is used to grab the message to display. Maybe we can use the output of profile_final() simply and treat it as a final message if the state it generated is "completed".

So that would simplify the three API functions: profile_final(), profile_final_task(), profile_final_message() to just profile_final(), which would either variable_set() the state or modify a parameter passed by reference and return page content to display (which would be part of the completed message if in the "complete" state). I am looking at lines 606 to 649 of the patched install.php

The other problem I faced is that it is not possible to address the "complete" page still. It is only possible to print a "complete" page in the same request, after some other state was processed and the state was switched over to "complete". If I switch state to "complete" and invoke another HTTP request, I get the usual "install already done" page. My use case requires batch processing of locale file imports in multiple HTTP requests, which displays a progress bar on every page. Now when we are complete, we cannot print the "complete" page on the same HTTP request, because it would be displayed below the 100% progress bar, which is awkward. We need to start fresh and ask the installer to display the "complete" page. This should be doable by separating the "complete" stage from the "already done" stage, going into "already done" only when the "complete" screen was shown. Now "complete" is used for both of these things, which is not nice.

Attached a complete install profile which you can try. It does offer a "Drupal localized" profile and an option to select the Hungarian language. Do that. Then after you enter site config settings, it starts a batch import of all translations, which it does nicely. After that, you get the "install already done" page, because we cannot address the completed page in a separate request.

Earl, the batch 'end-user' API consists of two functions that are defined in form.inc and are documented there. http://api.drupal.org/api/HEAD/group/batch pages do have a code formatting problem (dunno if this is because of my phpdoc or a problem with api.module) that make them pretty much useless ATM, but it is legible in the file.

The batch.inc file only contains non-outward facing functions that implement the processing engine, and as such, are not as extensively documented. I can of course try to be more verbose if this is considered insufficient or unclear.

Merlin, I don't think you need to understand batch.inc for anything related to *this* patch. I will do my work to integrate the locale import stuff, I just only reflected on a need to have a *separate completed step*. That is doable without ever touching batch.inc. Anyway, excuse me for mixing the language issue in, I did not test the installer without it, as the installer tasks are new in Drupal 6 and I was unable to look at it before. It will be possible to properly fix in a different patch. By the way there is a *really big* chunk of documentation (around 200 lines of phpdoc) about the batch API in form.inc where the actual API functions of batches live. People will use those API functions, and not the internal functions in the conditionally included batch.inc. Feel free to submit a bug report if you feel it is underdocumented still, we worked a lot with yched with feedback from Dries to simlify the API to a very small function set, and document it as cleanly as possible, providing example batches and so on.

I see you modified the _final() function to get the state by reference, which is nice! You did not comment on _final_message() being required (while the output of _final() is discarded at the same time), instead of simply using the output of _final() itself. I can take over for this remaining simplification if you feel you are overwhelmed and have no more valuable time to devote to this cause.

OK, here is an updated patch. The install profile task API is down to two functions: hook_profile_final_tasks() where you return an associate array of tasks to display in the task list and hook_profile_final() where you implement your state machine.

Additional modifications:

- separated 'complete' and 'done' page, which allows profile authors to provide a custom complete page and then advance to the 'done' step to finish off the installation (as noted before, this also has a side effect that we can redirect back to the 'complete' page, which now automatically advances to the 'done' step).
- added a 'Finished' step as Dries requested, which is ticked off as soon as you get there (it was a very simple modification, I just needed to add the 'complete' step to the list, the automatic tick off logic was already in the patch before).
- updated phpdoc in profile_final() to reflect changes

For those not interested in grabbing both the patch and the sample install profile I am going to post next, here is a video, which demonstrates two installs concatenated:
- a default profile install, which has a language selection page, but I really don't have those languages here, so the install goes in English
- a localized profile install, for which I have the Hungarian translations, so the install goes through in Hungarian (mostly), and the locale files are imported at the end in a batch (showed the translation status as a proof at the end :) Note that some stuff is still in Hungarian only because this is a 5.1 translation I am running the test with, so the new stuff (like task names) are not translated.

VIDEO: http://hojtsy.hu/drop/DrupalInstaller.avi (4.9MB)

As far as I see, this is ready to go.

As I was preparing the localized profile package, I found out that it did not change really (only two functions removed), so feel free to test with the zip I previously uploaded, it should work. (Of course we will get it polished for inclusion in Drupal :)

Couple minor points:

1.

+    'finalize' => st('Configure site'),

It might be better to call this state 'configure'? It better matches the task description. I don't feel strong about this, so feel free to leave this unchanged.

2. What happens when people have an existing Drupal 5 site that they upgrade to Drupal 6? I think the state-variable might not be properly set. Thus, other users would end up on the "create administration user form". I think we might want to check the upgrade path, as this might be a security breach. (People could create an account on the website.)

3. The hooks _profile_tasks() and _profile_final() were not particularly intuitive to me. I realize that _profile_final() is not a new function. Just wanted to point out that I had to look at the code to understand what this function does. I don't feel strong about this, so feel free to leave this unchanged.

4. The code comments in the default install profile mention that you can build a state machine. However, the PHPdoc does not really help me figure out how. I'm thinking that 2 or 3 lines of extra documentation would come a long way to get people up to speed on that. We really want install profiles to rock, so documenting this seems important.

5. It wouldn't hurt to document the architecture of batch.inc. I find this important too -- can be a separate patch though. Maybe yshed is reading this. ;-)

6. The improvements are absolutely wonderful. Exactly what I had hoped for. My new major gripe with the installer is that it doesn't help people take advantage of the multi-lingual stuff. If you watch Gabor's video, you can see that the multi-lingual stuff is really neat to get people that don't know English, or don't know English very well, started with Drupal. For many countries this is really, really important. To make a long story short: my gripe is that the installer does not explain people how they could take advantage of this. It might be good to have some on screen instructions: "If you want to localize the Drupal install process, or Drupal in general, please download a translation and put it in the following directory.". Right now, only very few people take advantage of this because you basically need to download a custom install profile (like the Hungarian Drupal distribution). I think, however, that relatively few people are inclined to do this. Anyway, this is something for a different patch. Just wanted to raise the issue so we can ponder about it more.

Good job all! :)

I am on fixing terminology here. Will follow up with a patch soon.

Something I was thinking about some time, is the addition of sort sort of multi-site installer.

Unfortunatly I'm not capable of writing/coding such a thing myself, but I think it would be pretty usefull if people are able to set the destination of the $domain.settings.php files for the various domains they would like to share the same drupal installation with. And offcourse the files/ directory.

I'm not sure it should be inside the scope of this beas... ehm... patch, but it surely is worth consideration IMO..

OK, updated patch as per Dries' suggestions:

- renamed "finalize" in the form and task names to "configure"
- renamed "state" to "task", because the task concept was already in the installer and state was just an alias
- renamed "complete" task to "finished" to reflect the the UI
- did not rename the 'done' task, although as discussed with Dries, 'end' might be slightly more clear (but IMHO not consistent with the user experience, which would make it harder to grok)
- added lots of phpdoc to default_profile_final() to document the default state machine, where does a profile hook into, what are the possible outcomes.
- renamed hook_profile_tasks() to hook_profile_task_list() to reflect naming of install_task_list(), which uses this profile hook
- renamed install_finalize() (as was in the patch) to install_tasks() as that is the place running the state machine, once the database is set up
- simplified variable_set()-ing of the state in install_tasks()

Also tested the security issue Dries mentioned. Sure, if the "install_task" variable was not set in the database, the installer could start over. Previously the installer checked for the system module being installed already, as an indication that the installation is done, so that was fine. Now I included the update path to set "install_task" to "done" when upgrading, so it is not possible to start the installer after an upgrade.

There are absolutely no changes on the user interface, so the video I posted earlier still stands. Tested the patch again with both the default install profile and the localized install profile we are working on (updated that profile to reflect my changes). Works fine!

(Will follow up later today with a patch for locale imports, so I am not posting the zip again).

OK, updated patch as per Dries' suggestions:

- renamed "finalize" in the form and task names to "configure"
- renamed "state" to "task", because the task concept was already in the installer and state was just an alias
- renamed "complete" task to "finished" to reflect the the UI
- did not rename the 'done' task, although as discussed with Dries, 'end' might be slightly more clear (but IMHO not consistent with the user experience, which would make it harder to grok)
- added lots of phpdoc to default_profile_final() to document the default state machine, where does a profile hook into, what are the possible outcomes.
- renamed hook_profile_tasks() to hook_profile_task_list() to reflect naming of install_task_list(), which uses this profile hook
- renamed install_finalize() (as was in the patch) to install_tasks() as that is the place running the state machine, once the database is set up
- simplified variable_set()-ing of the state in install_tasks()

Also tested the security issue Dries mentioned. Sure, if the "install_task" variable was not set in the database, the installer could start over. Previously the installer checked for the system module being installed already, as an indication that the installation is done, so that was fine. Now I included the update path to set "install_task" to "done" when upgrading, so it is not possible to start the installer after an upgrade.

There are absolutely no changes on the user interface, so the video I posted earlier still stands. Tested the patch again with both the default install profile and the localized install profile we are working on (updated that profile to reflect my changes). Works fine!

(Will follow up later today with a patch for locale imports, so I am not posting the zip again).

OK, updated patch as per Dries' suggestions:

- renamed "finalize" in the form and task names to "configure"
- renamed "state" to "task", because the task concept was already in the installer and state was just an alias
- renamed "complete" task to "finished" to reflect the the UI
- did not rename the 'done' task, although as discussed with Dries, 'end' might be slightly more clear (but IMHO not consistent with the user experience, which would make it harder to grok)
- added lots of phpdoc to default_profile_final() to document the default state machine, where does a profile hook into, what are the possible outcomes.
- renamed hook_profile_tasks() to hook_profile_task_list() to reflect naming of install_task_list(), which uses this profile hook
- renamed install_finalize() (as was in the patch) to install_tasks() as that is the place running the state machine, once the database is set up
- simplified variable_set()-ing of the state in install_tasks()

Also tested the security issue Dries mentioned. Sure, if the "install_task" variable was not set in the database, the installer could start over. Previously the installer checked for the system module being installed already, as an indication that the installation is done, so that was fine. Now I included the update path to set "install_task" to "done" when upgrading, so it is not possible to start the installer after an upgrade.

There are absolutely no changes on the user interface, so the video I posted earlier still stands. Tested the patch again with both the default install profile and the localized install profile we are working on (updated that profile to reflect my changes). Works fine!

(Will follow up later today with a patch for locale imports, so I am not posting the zip again).

Got Dries to more closely review the patch, and he said users will get confused by the task named 'Installation' in the middle. Rightly so... That task was previously used to signify that installation (database import) actually happens there. Now that we have the setup distributed to multiple screens, this does not stand anymore.

Anyway, that screen was used to present the 'missing modules' error message just after the config file is written but before the database tables were set up. That was an awkward place as noted by Dries, because this should have been done in the verify requirements stage already. Sure. I checked the code, and there was nothing which would stop us from putting the missing module check before the database configuration (modules are checked from the file system, the place of the future config file is checked from the URL, so the sites folder can be looked at for modules). That said, the missing module check is now folded into the 'verify requirements' stage.

BTW tested the installer with a missing dblog.module, and it noted it at the right place with the right task highlighted.

I hope we are really very close now :)

Well, Earl I forgot to thank you for fixing the language task issue, which actually fixed all occurances of language tasks (if no profile is selected, the 'default' profile is selected, so that was not a problem). Now keep our fingers crossed that this gets in :)

Reviewed it once more and all looks well. Good stuff! Committed. Thanks all.

update 6013 in the committed patch triggers undefined index warnings : see http://drupal.org/node/142969

Small (and late) nitpicking :

'Setup database' instead of 'Database setup' would match better the (verb + complement) pattern used by the other task names ('Verify requirements' and 'Configure site').

Lets' roll #83, #84 and #85 into one patch?

Here it is.
The fix for warnings on update also involves update 6014, which was in another commit.

OK, comitted the patch, thanks!

the clean url test during the install doesn't seem to be working. should i open a new issue for it?

Added it back in, and documented why do we need both, so we will not removed them to optimize later :)

dope, that fixed it and saved me the trouble of opening an issue. i want to offer up some high fives to everyone who worked this out because the installer just keeps getting better and better.

Anyone interested to make interface translation importing happen (as in my video above) in install time, the work of this patch is continued here: http://drupal.org/node/142869 It is still in need of reviews and testers. I needed to make some (small) changes to the task concept introduced here to accommodate it to interface translation importing, so people interested in the health of installer tasks should look there.

I can't get the installer to work after this patch (except by manually editing settings.php), when combined with this proposed change to the menu system: http://drupal.org/node/137767

Any ideas?

Pwolanin, I have seen Dries mentioning that he tried that patch today and it worked with the install, so I don't really see what is the problem. Although the installer no contains some menu_rebuild()s, which you seemingly remove in your patch from all around Drupal (but not the installer). I don't really see why those menu_rebuild() calls are to be removed, but anyway, this might be a problem with the installer. Continue on that issue, if you have problems.

Yes, I got it working, but I opened a new issue for some follow up on the documentation and permission checking:
http://drupal.org/node/143418

The installer time language importing extension of this patch could use some reviews still! It would be great if someone could review it, so we can advance with that feature (we need to have module/theme enable time importing too). Issue: http://drupal.org/node/142869 Remember, that I needed to make some (small) changes to the task concept introduced here to accommodate it to interface translation importing, so people interested in the health of installer tasks should look there. Thanks!

Added a documentation issue here to update the install.txt (it contains two other related updates, so this is why I have the separate issue): http://drupal.org/node/144256 Please review!

The patch does fix the problem. RTBC +1

Critical. None of the node/add/* links work without this patch.

Tested and works great.

Committed, thanks.

I just CVSed head and used the installer to set a new site up. But the installer form didn't save the site name or site email and it didn't setup cleanurls.
I tried it twice to be sure.

Please open that as a new bug issue. This thread is long enough as it is. :-)