Improve installer usability: database configuration

Here are my stabs at some text replacement, numbered according to the original attached screenshot. (Text in quotes; responses to items on the png are not):

1) "Please provide the following information to configure your Drupal installation."

2) "Select the database your Drupal installation will use. If you have difficulty, try the [Drupal database troubleshooting page]."

3) In general I don't think the order of dbuser/pass/name matters but in terms of order of significance, name is probably first.

4) "This database must already exist, and should be provided by your database administrator or hosting provider."

5) "The hostname or IP address of your database server. Will probably be localhost."

6) I do not think these items need to be collapsed.

I agree the database name should be above the other database information.

I know on Dreamhost, the database host is not localhost. I'd assume that on most shared hosting, the database name is not localhost. Would it be too wordy to list some of the more common situations where 'localhost' isn't going to work, like users on shared hosting?

I love annotated screenshots! Great job, Kristjan. I agree with all of your points. Sholuld be a fairly easy patch.

After a person puts in their mysql username and password, is it possible for the install script to try the likely candidates like localhost, remotehost, remotemysqlhost etc and then auto-populate the field.

Also (if there are appropriate mysql user rights) could the script also query for a list of databases?

I honestly think those options veer into the realm of 'trying to be too smart.' There are too many ways for that to go wrong: permissions, bad guesses, confusing the user with loads of options (none of which are correct), etc.

Provide a sensible default at this point with a minimum of fuss, and note that if it doesn't work, they should ask their hosting provider what the address of their database server is. Similarly, the name of the database.

Eliminating the unecessary verbiage does far more for usability on this screen than a lot of complicated code to guess what a user should find out from their host.

Actually, the first screen the user is most likely to encounter is the error message about making settings.php writable (which is another rather unfriendly screen):

http://acko.net/dumpx/installer-screen-2.png

Another possible first screen is the profile selection page, which appears if you have multiple profiles in /profile:

http://acko.net/dumpx/installer-screen-1.png

Perhaps we should refactor the profile selection page to double as a welcome page. We can even have a short paragraph about multiple Drupal profiles there. Then, if you have multiple profiles available, this is where you would choose them, otherwise there is a simple "Install Drupal" button.

This would mean that you could still run install.php?profile=some_profile with a pre-made settings.php to do a fully automated install (a requirement for some).

I'd like to have 2 profiles:

1. A barebones profile like we have now: nothing setup or pre-configured, you have to start from the minimal setup.

2. A quickstart profile: we setup a contact form, an about page with a clean URL (?q=about), we create an admin block subscribed to the security announcements, and we create an example/welcome node or two. (Most people want to set these up anyway.)

Dries, thanks for that comment. I've got a simple setup wizard working (code-wise) in my sandbox but hadn't yet figured out what 'hand-holding' steps it should take. I'll use that set of steps as the skeleton...

Anyone going to take a lead in this?

Here's a quick stab at cutting down the amount of text that's presented to users.

...And a screenshot of same.

After a conversation on #drupal, it was suggested that the 'db_type' field should be hidden if only one option is available, and an error should be displayed if NO options are available.

If only one db_type is available, it's displayed as a textual note in the 'advanced options' section.

In the majority of cases, with this setup, users will only have to enter three values.

A slightly scaled-down side-by-side comparison for those who don't have time to run the patch.

kika, a couple notes:

the db information ONLY appears down below when ONE db type is supported by the server. If multiple types are supported, the selection appears up at the top again.

I'm not sure if that's confusing or not; I think it qualifies as hiding needless options. But I'd love feedback on that field in particular. Overall, I think hiding the infrequently-used options and cleaning up the text have a really big impact and make it much simpler.

For the eye (and for semantics), it might be nice if the form elements at the top where also in a form element? (But one that can't be collapsed.)

Not sure though.

Dries, here's a screenshot of the page with everything in a fieldset. I'm not sure I like the feel of it -- everything appears more cluttered and squished, though I suppose some theming and CSS could change that.

Here's the patch for the above screenshot. I still lean towards the one in comment #14 unless we do some serious CSSing to make it look cleaner. But I think the improvements are definitely worth committing. Thanks, kika :)

I'm not fond of the fieldset.

I like it better with the extra fieldset (and it's semantically correct). I think this is ready to go? If so, set a RTBC.

Attached is a patch that moves the database type notice to the top fieldset, integrated with the 'Enter these pieces of information...' text when there is only one database type.

And the screenshot.

I didn't like that one. After consideration, it can be narrowed down further. Now, if there is only one DB type available, the description of the db_path field simply reads:

"The name of the %db_type database where your Drupal data will be stored."

The information is there, but it's unobtrusive. Yay.

Committed to CVS HEAD. Thanks.

My installer (http://drupal.org/node/33581#comment-115069) captures the database errors and runs a wizard to install a new site.

The screen shots are at http://drupal.org/node/33581#comment-114471 and you can see that the theme matches the os you are using because the css uses system information.

The wizard requires the user to enter the drupal dbuser password for security and can create the dataases the first time if the user enters the dbadmin user and password if the host permits dbadmin login from that IP. (Many hosting providers require that you create the database and drupal dbuser through a control panel first).

Once you set the basename of the database server and prefix you never need to edit settings.php for a new site. It only takes a few seconds to install a new drupal site on the same server.

The only time settings.php needs to be changed is if you want to enable the debug option (not recommended to be left enabled on a live site).

I know that I am not permitted to contribute to Drupal, but have a look and use what you like.

lekei -- It looks like the system you designed was set up to run under 4.6, while this one is built (mostly) on the work done by CivicSpace labs and the new hook_install() infrastructure introduced in Drupal 4.7. Please note that no one has ever said you are not welcome as a contributor to Drupal. You're as welcome to post patches and issues as anyone else here. :-)

My installer works on 4.6 and 4.7 and for modules that work on 4.7 but do not have install files but rather still have .mysql and .pgsql files (like Drupal itself).

It also automates some key settings like timezone (defaults to the timezone of the person creating the site), the site name, clean urls etc.

It also adds a "safe mode" to allow you to recover if some options you set (like clean urls) break your server.

Most of the magic happens in settings.php where it is relatively safe from the ever-changing code of Drupal.

I can't submit patches because my development environment is Windows.

the comments you've brought up aren't really related to this issue; if there are bugs or suggestions for improvements to the 4.8/5.0 installer, opening a new issue is probably best.

I can't submit patches because my development environment is Windows.

What?! That's no excuse. :) There are a plethora of options for patching on Windows. But agree with Eaton, best spot for new features is a new issue.

Thanks for the feedback kika, and for the patch, Eaton. :)