Closed (works as designed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
install system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
16 Mar 2013 at 14:44 UTC
Updated:
29 Jul 2014 at 22:03 UTC
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
Comment #0.0
tlattimore commentedupdating path
Comment #1
ssalat commentedSame 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
Comment #2
ssalat commentedSame 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"Comment #3
traviscarden commentedFailure to install is definitely a critical problem.
Comment #4
alan evans commentedI'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.
Comment #5
alan evans commentedNote 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.
Comment #6
traviscarden commentedI'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:I've tried several times, each time
git clean -fd-ing and making sure that the files directory is properly owned andchmod-ed 777. It doesn't matter which install profile I use.Hopefully this helps. I'll presume to set the issue back to critical.
Comment #7
ParisLiakos commentedTravisCarden did you removed settings.php?
Here is a script i run when i want to reinstall d8
Comment #8
alan evans commentedYeah, 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?
Comment #9
tim.plunkettThe 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.
Comment #10
minneapolisdan commentedI 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.
Comment #11
alexdmccabeIgnore -- commented in wrong issue by mistake.
Comment #11.0
alexdmccabegrammer