Drupal without DB but with site config throws uninformative error

Same error happened for me (same commit), I had instead setup a settings.php config file (copied from default.settings.php), I entered in my new database details and as the original post I had my database emptied. I expected Drupal to install similar to D7 but received same error described in original post.

Related: #1895100: Remove pre-existing compiled PHP code when re-installing Drupal core

The error still happens after applying the patch.

With the scenario described in the main issue the following error is displayed on the homepage after the database is purged:

Fatal error: Class 'Drupal\rest\EventSubscriber\RouteSubscriber' not found in core/vendor/symfony/event-dispatcher/Symfony/Component/EventDispatcher/ContainerAwareEventDispatcher.php on line 142

I started the installer (install.php), was able to select the language and profile, it verified the requirements, found the old settings.php file with the database configuration files, as it was running the "installation profile" step of the installer it fails with the error described in the issue summary:

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://d8.dev/core/install.php?langcode=en&profile=standard&id=1&op=do_nojs&op=do StatusText: OK ResponseText: Fatal error: Call to a member function get() on a non-object in core/modules/views/lib/Drupal/views/ViewStorageController.php on line 26

Please note that this issue does not talk about install.php.

This issue is about visiting the actual site (index.php) after dropping the database.

Therefore, all of the changes to install.inc should be reverted and removed from this patch.

Due to that, #11 sounds unrelated too, but I'm not 100% clear on that.

@sun: Would you recommend merging problems during the installation process into #1895100: Remove pre-existing compiled PHP code when re-installing Drupal core or adding a new issue?

The patch from #13 rerolled, and I fixed some whitespace errors that git-apply reported.

Ack, the last patch missed MaintenanceContainerBuilder.php.

The patch in #19 does not always do what is described.

These scenarios all have the patch from #19 applied.

Scenario #1: Tables removed.

• Start off with nothing in sites/default and an empty database.
• Install D8 with the standard profile.
• After the site has finished installing, remove all tables from the database so that the db values in settings.php are still correct.
• Load the homepage, the following fatal error is returned:
  

  Call to a member function get() on a non-object in core/includes/config.inc on line 105

Scenario #2: Database removed.

• Start off with nothing in sites/default and an empty database.
• Install D8 with the standard profile.
• After the site has finished installing, remove the entire database so that the db values in settings.php are no longer correct.
• Load the homepage, the following fatal error is returned:
  

  Call to a member function get() on a non-object in core/includes/config.inc on line 105

Scenario #3: Tables removed and compiled PHP files removed.

• Start off with nothing in sites/default and an empty database.
• Install D8 with the standard profile.
• After the site has finished installing, remove all tables from the database so that the db values in settings.php are still correct and remove everything from sites/default/files.
• Load the homepage, the following error is returned:
  

  The website really has encountered an error. Please try again later.

I split up the config() function from \Drupal\Core\Config\Config to the following:

function config($name) {
  $container = drupal_container();
  $factory = $container->get('config.factory');
  $config = $factory->get($name);
  return $config;
}

The error then pointed to the second line, meaning that the value returned from drupal_container() is invalid.

The documentation for drupal_container() says:

Retrieves the Drupal Container to standardize object construction.

@deprecated This function has been replaced by the \Drupal class. Use that instead.

So, does this class need to be updated to a new structure before anything else should proceed?

Tag.

This is related to #1875086: Improve DX of drupal_container()->get().

This patch changes the direction slightly and move responsibility to the error handling system to ensure it has enough of a container to function properly.

Without this patch

With this patch

I believe this is release blocking as the current message when the db is not available is very very obscure.

Interesting - shouldn't we then also remove that line in index.php ? That one is just completely not informative :)

In reviewing this issue I am using D8 from git as of 21:35 on 11-Dec, #51560a3a0424

First, without applying a patch:
-Creating a default site and then dropping the tables in the database using drush sql-drop results in the following message on an otherwise white browser screen:

If you have just changed code (for example deployed a new module or moved an existing one) read http://drupal.org/documentation/rebuild

- Creating a default site and then dropping the database completely results in the same message.

I applied the patch from #25, which succeeds with an offset of 10 lines to one of the two files, and recreated the site.

Dropping the tables as before now returns a similar screen to that shown in #25, but it's not the same. In particular, the Drupal logo and 'please try again' messages are missing. However the central error is present and moderately clear. A screenshot is attached.

Probably RTBC but curious about the logo so not changing status.

Rerolled the patch from #25, git diff, otherwise unchanged.

PHP 5.5.5
MariaDB 5.5.32
Drupal 8.x HEAD

Database stopped

before

after #28

All tables dropped

before

after #28

Ref. #29. No end users get this.

I fixed the error and exception handling in the installer very recently. In case of an error, you should see a verbose backtrace now.

Can you test again with latest 8.x/HEAD, please?

Note that the patch in #2194111: Error handler throws exception when service container is not (fully) available yet fixes the last remaining "errors caused by errors" problems. Once that has landed, we should be able to properly debug what's going here.

Now fixed. We could do without the literally printed html tags in the exception message, but that's minor.

Exception: <ul><li>To start over, you must empty your existing database, delete your active configuration, and copy <em>default.settings.php</em> over <em>settings.php</em>.</li><li>To install to a different database, edit the appropriate <em>settings.php</em> file in the <em>sites</em> folder.</li><li>To locate your active configuration, view the appropriate <em>settings.php</em> file in the <em>sites</em> folder.</li><li>To upgrade an existing installation, proceed to the <a href="http://8.x.localhost/core/update.php">update script</a>.</li><li>View your <a href="http://8.x.localhost">existing site</a>.</li></ul> in install_begin_request() (line 526 of core/includes/install.core.inc).
install_begin_request(Array)
install_drupal()

Filed #2194533: "Drupal is already installed" exception is printed like any other exception for that

this is still an issue in drupal-8.0.0-beta12
How should I wipe and reinstall drupal to avoid this?