I am receiving this error during the install process in my local dev environment:

Fatal error: Class 'Drupal\user\Plugin\Core\Entity\User' not found in /path/to/drupal-8/core/includes/bootstrap.inc on line 2051

This is occuring when I am installing with the Standard profile after the step where I enter my db name and creds and clicking "Save and continue".

My local environment:

- Mac OS 10.8
- PHP Version 5.3.18
- Apache/2.2.22

Comments

tlattimore’s picture

Issue summary: View changes

updating path

ssalat’s picture

Priority: Normal » Critical
Issue tags: +installation fatal problems

Same here!

PHP Fatal error: Class 'Drupal\user\Plugin\Core\Entity\User' not found in /var/www/drupal/core/includes/bootstrap.inc on line 2058" while reading response header from upstream, request: "POST /core/install.php?langcode=de&profile=standard HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000"

- Nginx
- PHP5-FPM
- Ubuntu 12.10 LTS

ssalat’s picture

Priority: Critical » Normal
Issue tags: -installation fatal problems

Same here!

PHP Fatal error: Class 'Drupal\user\Plugin\Core\Entity\User' not found in /var/www/drupal/core/includes/bootstrap.inc on line 2058" while reading response header from upstream, request: "POST /core/install.php?langcode=de&profile=standard HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000"

traviscarden’s picture

Priority: Normal » Critical

Failure to install is definitely a critical problem.

alan evans’s picture

I've been unable to reproduce this locally, Mac/Apache2.2.23/PHP 5.3.18. Given the initial report states similar versions, this doesn't seem stack-related, though it seems feasible there might be a file permission issue involved.

I'll try a couple of different install methods and see if I can break it somehow.

Can either of you try starting with a fresh checkout (make sure you're on HEAD and no cruft lying around). Seems like you are using slightly different codebases also, given line number differences reported (which figures, given the 15 day gap).

I'd usually ask for more detailed steps to reproduce just to ensure that I'm doing the same thing, but I can't really see any way the STR from the original post can be misinterpreted.

alan evans’s picture

Priority: Critical » Normal

Note also that the line numbers cited here don't match the actual only use of [Drupal\user\Plugin\Core\Entity\]User in this file, which is now on 2015 of bootstrap.inc, so these reports don't appear to be from latest HEAD.

I've now tried full manual installs using the /default and using multisite, as well as Acquia Dev Desktop multisite install, and haven't been able to observe a breakage in any case.

Downgrading to normal until we can get more details ... not sure we can keep this open much longer unless we can get more confirmation that this is broken.

traviscarden’s picture

Priority: Normal » Critical

I'm working from the 8.x branch as it is this morning, at 11:41:59 +0000 (12:41 +0100)—e7d8f36. Here's what I get at core/install.php?langcode=en&profile=minimal, after submitting the first form in the installation process:

Fatal error: Class 'Drupal\user\Plugin\Core\Entity\User' not found in /home/quickstart/websites/d8.dev/core/includes/bootstrap.inc on line 2015

Call Stack:
    0.0001     333256   1. {main}() /home/quickstart/websites/d8.dev/core/install.php:0
    0.0006     353112   2. install_drupal() /home/quickstart/websites/d8.dev/core/install.php:31
    0.5310    3047968   3. install_run_tasks() /home/quickstart/websites/d8.dev/core/includes/install.core.inc:88
    1.5411    3302672   4. install_run_task() /home/quickstart/websites/d8.dev/core/includes/install.core.inc:472
    1.5411    3304448   5. install_bootstrap_full() /home/quickstart/websites/d8.dev/core/includes/install.core.inc:612
    1.5412    3304492   6. drupal_bootstrap() /home/quickstart/websites/d8.dev/core/includes/install.core.inc:1642
    1.5750    3428688   7. drupal_session_initialize() /home/quickstart/websites/d8.dev/core/includes/bootstrap.inc:2107
    1.5751    3429480   8. drupal_anonymous_user() /home/quickstart/websites/d8.dev/core/includes/session.inc:258

I've tried several times, each time git clean -fd-ing and making sure that the files directory is properly owned and chmod-ed 777. It doesn't matter which install profile I use.

Hopefully this helps. I'll presume to set the issue back to critical.

ParisLiakos’s picture

TravisCarden did you removed settings.php?

Here is a script i run when i want to reinstall d8

# /bin/bash
sudo rm -rf /var/www/d8/sites/default/files/php/
rm -rf /var/www/d8/sites/default/files/config*
rm /var/www/d8/sites/default/settings.php
cp /var/www/d8/sites/default/default.settings.php /var/www/d8/sites/default/settings.php
chmod 777 /var/www/d8/sites/default/settings.php
mysql -uroot -p1234 -e 'DROP DATABASE d8;CREATE DATABASE d8;'
alan evans’s picture

Yeah, critical seems appropriate for the time being, though I'm hoping this will turn out to be not a real bug, given difficulties in reproducing it.

@rootatwc - have you tried to reproduce the bug also? (the more the merrier ;)) Just to check that I'm not the exception in *not* being able to reproduce it. I'd hope that automated tests would catch a breakage like this though before commit.

@TravisCarden - presumably git clean ignores anything in gitignore, is there any chance that cleaning up left some cruft lying around (or were you testing with a completely fresh clone that has never had drupal installed?) Did you manually verify that everything from sites/default was reset to its initial state (including making sure settings.php is a fresh copy from the default)? Is it an option for you to start from a fresh clone to test, and can you test both installing into default *and* multisite installs just to see if there's any difference?

tim.plunkett’s picture

Priority: Critical » Normal
Status: Active » Closed (works as designed)

The autoloader used was just changed in #1658720: Use ClassLoader instead of UniversalClassLoader, and the first reinstall I tried gave me this error.

However, dropping the DB and removing my sites/default directory (including the config and php dirs, and settings.php) and starting over worked fine.

minneapolisdan’s picture

I just found that having a settings.php file is what was causing the error. I thought, as in Drupal 7, that I should have an empty settings.php file before installing, but it just caused issues. Maybe because the installer was trying to create a new one and couldn't overwrite the blank one? Once I got rid of settings.php file, it installed ok.

alexdmccabe’s picture

Ignore -- commented in wrong issue by mistake.

alexdmccabe’s picture

Issue summary: View changes

grammer