Attempting to use update.php without having configured a database in settings.php results in incorrect/misleading error message

Marked #931492: Upgrade from D6.19 fails stating requirement for pdo while it is already installed as a duplicate.

Ditto. Happened to me too when I mistakenly thought I'd saved the settings.php file.

I'm going to go ahead and bump this to critical. Drupal giving just plain wrong error messages that will actively prevent someone from installing/updating it, are release blockers IMO.

Wow. I was going to ask, "Does this bug really make D7 useless?" but apparently Angie thinks it does and far be it from me to question her. :-)

I also think this isn't critical, the only way to get here is to not follow the upgrade instructions at all. Here's an untested patch for it though.

+    else {
+      print '<h2>There is no database connection information available. Copy the $db_url variable from your Drupal 6 settings.php file to your Drupal 7 installation, then try again.</h2>';
+      exit();

Is it correct ?

$db_url in d7 is

 * Database configuration format:
 * @code
 *   $databases['default']['default'] = array(
 *     'driver' => 'mysql',
 *     'database' => 'databasename',
 *     'username' => 'username',
 *     'password' => 'password',
 *     'host' => 'localhost',
 *     'prefix' => '',
 *   );
 *   $databases['default']['default'] = array(
 *     'driver' => 'pgsql',
 *     'database' => 'databasename',
 *     'username' => 'username',
 *     'password' => 'password',
 *     'host' => 'localhost',
 *     'prefix' => '',
 *   );
 *   $databases['default']['default'] = array(
 *     'driver' => 'sqlite',
 *     'database' => '/path/to/databasefilename',
 *   );
 * @endcode

In d6 it is

 * Database URL format:
 *   $db_url = 'mysql://username:password@localhost/databasename';
 *   $db_url = 'mysqli://username:password@localhost/databasename';
 *   $db_url = 'pgsql://username:password@localhost/databasename';

@sivaji - it's correct because the hunk just above this one translates the Drupal 6 format to the Drupal 7 one.

We should also mention $db_prefix in the message, as copying only $db_url when $db_prefix was set could result in some serious trouble (e.g. a site that has '' (no prefix) and 'staging_' as prefixes).

Not sure what the text should be, this is the relevant bit from UPGRADE.txt:

8.  Copy your backed up "files" and "sites" directories to the Drupal
    installation directory. If other system files such as .htaccess or
    robots.txt were customized, re-create the modifications in the new
    versions of the files using the backups taken in step #1.

The instructions here are to copy the D6 settings.php directly into the D7 installation, which isn't what I'd do personally, since settings.php changes between major versions, and I'd rather have the new documented variables available to me.

So first, I think we should just point people to upgrade.txt

Second, I don't like the instructions that are in upgrade.txt, and they certainly aren't great for explaining what to do to people who find themselves in this situation.

Tagging

Here's one that just points to UPGRADE.txt, I am tempted to mark this issue postponed on #295255: Clean-up the upgrade path: UPGRADE.txt, in fact I'm going to do that now and bump that to critical.

+      print '<h2>There is no database connection information available in settings.php. Follow the instructions in UPGRADE.txt to proceed.</h2>';
+      exit();

Instead of doing this, I think we should just add it via update_extra_requirements() instead, so they get it as part of the nice pretty status report. (We could add a condition on the PDO driver check later to make sure it doesn't also trigger.)

If you do leave your site without database connection info in settings.php for more than a very short amount of time it's kind of a weird state to be in. (For one thing, wouldn't anyone visiting the site get redirected to install.php and be able to start going through the installer, and in some cases, e.g. a server with no root password, maybe even be able to perform a successful installation?) But I guess we do have to cater to it somehow.

I reckon you could install on a server with sqlite pretty easily, only needs a writable file path to create a new database and no password.

This has also hit a few people so I'd like to fix it before the next beta.

Un-postponing, because webchick gave #295255: Clean-up the upgrade path: UPGRADE.txt the "beta blocker" tag, so let's assume that by the next beta (which is all we need to worry about in regards to update procedures), we'll have an UPGRADE.txt file that doesn't give people the wrong installation steps, and that therefore, can be referred to.

I think #11 is an adequate solution, so +1 from me on that.

#12 may be an improvement, but unless someone feels inspired to roll that patch very soon, let's go with #11, and then have a separate issue (would it really justify a priority greater than "normal"?) to make improvements.

Well. While I'm all about the problem getting fixed ASAP, David's right that the current way is very non-Drupal and skirting our established mechanisms for this. Over at #722974: Install script returns a blank page for PHP4, PHP 5.1 (should display *something* instead) we have to do it that way, because the alternative is fatal errors. But here I think we should use the standard hook_requirements() mechanism, if we can.

David indicated he thinks he can roll a patch for #12 later today. If he doesn't get to it, I'll do it.

Looks like I was wrong. We can't do the normal requirements check (at least not at all easily) because in the normal workflow we'd have to bootstrap the database before that, which we can't do here...

So instead, this is pretty much just the same as the above patch, with a few small cleanups.

No need for a new message because when the original bug is fixed we redirect to install.php anyway, which has been the case for several releases now.

My patch with David's comment.

edit: actually I changed from the !empty() to the isset as well, so it's all David's patch with the attempt to print a message just ripped out.

#22: 887288.patch queued for re-testing.

Somehow I don't think this broke the filter formats access test.

Hm, I guess it is not so bad just doing that. Redirecting to install.php is pretty weird, but it does appear to be the case that the same thing would have happened in previous Drupal versions.

There was an extra "`" character in the code comment and there shouldn't be a space before it, because the elseif() is related to the previous clause. Fixed in the attached - still RTBC.

Great. Committed #26 to HEAD. Nice work, folks!