The first screen the user sees when pointing
is following

- huge and scary 'Unable to connect to database server'
- the tiny messages proposing go to to installer page
- the scary "access denied for user..." db error message

can we make the initial screen more friendlier?

a) detect if the installer has not yet be run and redirect user to installer next screen immidiately. Optionally that next page needs some changes in text to be more welcome-y

b) if it is not possible, rework the initial screen and do get rid of the scary feel provide more of a 'Welcome'-style message with options to go for installer or troubleshoot db

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kika’s picture

FileSize
88.52 KB

Added Wordpress initial installer screen as a reference

kika’s picture

Version: 4.7.2 » x.y.z
kika’s picture

there seems to be a problems with automatic redirection to an installer page
http://drupal.org/node/73993

if anybody could confirm this, the work should continue on improving the initial "go to install/mysql error screen" but I still feel it's less than optimal.

Steven’s picture

Indeed: without a database connection, we cannot make a difference between a technical problem with the database or Drupal not having been installed yet.

This mechanism was chosen over a permanent $installed_profile = "default" variable in settings.php, because this would mean you could not easily re-use settings.php files.

There is one thing we could do though: check for the default $db_url (mysql://username:password@localhost/databasename) if the connection fails, and do an automatic redirect in that case. While it's a bit of a hack, it is IMO a worthwile usability enhancement. Besides, we do not allow installation with "username/password" anyway.

The only case where this redirect would not work is hosted installations that already provide a settings.php file.

merlinofchaos’s picture

I'm +1 for treating the default as a special case and forwarding directly to the installation section. We already treat it as a special case for denying anyway, so it's perfectly consistent.

eaton’s picture

Agreed. Special-case redirection is a good thing in this situation.

Bèr Kessels’s picture

... and if in settings.php this is found, don't redirect:

$conf = array(
  'ignore_install' => 'false',
  ... default (commented) example variables ...
);

No-one needs to set that variable. But those that offer hosting, or some other concept where they really don't want their users to touch installation, can set that in their settings.php.

After all: we certainly don't want our not-yet-configured sites to sit there waiting for a kiddie to pass by and fill out our installer...

Steven’s picture

FileSize
3.09 KB

Ber: The redirect does not open any holes, it simply makes install.php more accessible. If your security model relies on a script kiddie to not be smart enough to append "install.php" to a URL, you need to have your head checked...

Patch attached.

Bèr Kessels’s picture

No. What I am saying is that my security model relies on the fact that I remove the install (and update) php files
This patch hardcodes install.php even if it is not wanted/needed. That is something I find shortsighted. Why can't we check for a variable? It's simple and brings a lot more power and flexibility to those that do not want (nor have) the installer avalailable?

And thanks for being polite and telling me to get my head checked. Lets try to keep personal remarks from the issue queue. we are not some bunch of quibbling free-time hackers, but a group of professional web developers (Or so I sincerely hope). Lets act like that.

kika’s picture

steven's patch work as expected, +1 from me

should we reword now the database configuration screen title and intro since this is possibly the first thing user sees -- being more welcome-y? see http://drupal.org/node/75256

Dries’s picture

Patch works for me but it doesn't feel right from a development point of view.

1. + $install = TRUE;: is this required? Global variables like this are ugly.

2. The other database backends need to be updated.

3. It would be a _LOT_ cleaner if we could perform this check outside of the database backend (if the database backend would just return an error state). It's a big hackish right now.

We could do the following in index.php or somewhere in bootstrap.inc (after loading settings.php):

  if ($db_url == 'mysql://username:password@localhost/databasename') {
    goto installer
  }

It would keep the database backends free of cruft and has neglible overhead.

Steven’s picture

MySQL is the default database back-end, so it does not make sense to include the check in the other database backends. I also think it's kind of wasteful to do this check for every page request.

We know that an uninstalled Drupal leads to a database connection error. So that's where the check should be, IMO.

Dries’s picture

Steven: I think it is spaghetti code.

Dries’s picture

Status: Active » Needs review

That said, it's an important improvement so it is acceptable if we can get rid of the $install = TRUE;.

Dries’s picture

Gosh, I just looked at install.inc and figured out why we need the ugly global $install variable. It's a bit of a mess but I can understand why it's needed. I guess we can go ahead and commit the current code and refactor it later.

Steven’s picture

Status: Needs review » Fixed

I removed the global $install variable. I'm not sure why the original author used it really, install.inc should remain an API.

Other than that, I left the check in db.mysql.inc. It is really non-trivial to move it elsewhere... we cannot place it in index.php, because the database bootstrapping aborts on error and dies. To put it in bootstrap.inc, we need to also check if we're not already in install.php (which also uses the bootstrapper) and then we'd be checking on every page load.

Committed to HEAD.

Dries’s picture

No one else to review this?

beginner’s picture

Priority: Normal » Critical
Status: Fixed » Active
kika’s picture

In order to safely close this issue following issues need to be solved (in separate issue threads?)

1. Improve the 'dir not writable' error on installer. Add troubleshooting info: a short compilation based on
http://drupal.org/node/34022 + link to a handbook + alternative route via editing settings.php manually

2. Possibly compile a "into screen" based on Steven's idea http://drupal.org/node/75256#comment-118491
Here's again Wordpress intro screen for reference
http://drupal.org/files/issues/wp_initial.png

3. Based on the results on above, rewrite INSTALL.txt

kika’s picture

1. is now living in http://drupal.org/node/76591

kika’s picture

Priority: Critical » Normal

lowering the prio

LAsan’s picture

Version: x.y.z » 7.x-dev

Whats this task current status?

ScoutBaker’s picture

Status: Active » Fixed

The installer has been reworked significantly between 4.x, 5.x and 6.x. I would call this one fixed.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.