Core

If your db allows successful authentication with empty username and password (which is unlikely and hopefully only the case on dev systems), then the step is not rendered. This is correct so far.

The other option is to not allow empty user + pass, but then those people who use this will scream ... any ideas?

Yes, that's on a dev system.

As there is no LocalConfiguration.php we have no settings yet. So the question is, where does this configuration come from?
Also for users which have user+pass empty on their dev systems, they can't change the database driver. For example if they try to install TYPO3 with oracle. So my idea is to differ between an empty setting and no setting.

For various reasons, default settings are calculated during this install step before the step is rendered. in this process username + pass are set to empty string if not set.

What you want is basically:
If in "first install" processes, and if username + password are empty, and if connect is successful, then still force rendering of the connect step exactly once and show some message "hey, i've detected that a connect with empty user+pass is possible. if you do not want that then please change the settings now".

Problem is that it is not simple to ensure this step only comes up once during the installation and not all the time, because of the redirect logic in the step installer. And I do not want to store yet another setting in LocalConfiguration to track this state. Maybe we could track this info in the install tool session, that may be the most clever idea. Still, a construct like that will uglify the code and add even more complexity to this pretty complex class.

Imho, this topic is not a blocker and more a minor glitch for a (hopefully) rare edge case. Whats your feeling on this issue, Alex? If you think it is more important, I could try to see how it feels to solve this in the code ...

IMHO: It should somehow be possible to change the empty user/pwd, because otherwise it is very likelythat the insertion of data fails afterwards, since it is very unlikely that an anonymous user has write access to the whole DB.

in this process username + pass are set to empty string if not set.

Then this isn't a good handling, you can't predict some defaults and don't give the user the possibility to change them. You will need a way around, also for other settings. For example if IM and GM is installed you may default to IM but if the user wants to work with GM or another one in another directory?

So we need a generalized form for such things or we can't skip such steps.

@Alex: Ok for the db thing. Steffen Mueller now also mentioned this detail ... it seems we will have to solve that ...

But for other settings like "im/gm", the installation procedure checks what is available and usese "the best option" automatically that has the highest priority. This should give "sane" settings by default without user interaction. If you later on want to change that, you can still do that with the new "configuration" option in install tool.

IMO using anonymous DB user is an edge case. If an anonymous user exists, it must not prevent you from configuring a different user. Otherwise I cannot install TYPO3 using the install tool.

To me this is a blocker.

I tested this on a fresh Debian Wheezy with default MySQL. It seems Debian MySQL creates an anonymous DB user by default.

Steffen Müller: install tool <6.2 supports anonymous DB user. but the dialog for user/pass is always shown.

gnaa ... ok, we'll have to find something ...

the installation procedure checks what is available and usese "the best option" automatically that has the highest priority.

But how you want to know if your selected option is the best one? Maybe for "new users" the setup will be easyier but for professionals it will be harder to setup.
Maybe we can show the user an "link" with the message "TYPO3 CMS Install choose a guessed option. Click here to get more information about." And if you click it, a hidden field will open which shows the guessed options with the possibility to change them.

On the other side, we have not enough time for such things so fixing the DB issue and let the rest open as feature for TYPO3 CMS 10.0 should be ok for now. ;)

@Alex: Please do not shift topic. The "configuration preset" and automatic selection of "sane" values and good presets is a good (!) thing and professionals can already change that later on. The "best" option is also pretty clear: for example we know that mbstring is a bit quicker than iconv (at least to my measurements), so we use it if available. if your numbers differ, we could argue about that specific point again.

But still, this issue here is about db settings, and those have nothing to do with the 'configuration presets'.

Quote from Anja:

I set up a brand new ubuntu server, everything is (intentional) out of the box. The install Tool does not ask for database credentials, but connects on its own and finds the test database.

#51540 solves it for me