Problem/Motivation

When reinstalling Drupal in the same directory as a previous installation, in previous versions you could just drop all the database tables and run install.php. This no longer works in Drupal 8.x.

The reason is that Drupal 8.x puts some compiled files in:
sites/default/files/php
sites/default/files/config
sites/default/files/styles
What's more, all of these files are owned by the web server user, so they can't even easily be removed in general (on a Linux system, you would need to use sudo to remove them).

If the "php" or "config" files are present and you run install.php, you get errors on-screen, although the installation might actually work. I am not sure if the "styles" files cause any particular trouble or not?

Proposed resolution

The installer, if it figures out that there is no database and it is going to install Drupal, should remove the config, php, and styles directories under sites/default/files.

Remaining tasks

Make a patch. Test it. Perhaps make an automated test if possible?

User interface changes

Drupal will be able to reinstall after just removing the database tables.

API changes

None.

Original report by mgifford

I just got this error in my error log:

PHP Fatal error: Call to a member function get() on a non-object in core/modules/views/lib/Drupal/views/ViewStorageController.php on line 26, referer: core/install.php?langcode=en&profile=standard&op=start&id=1

After getting this AJAX error:

The installation has encountered an error.
Please continue to the error page
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://example.com/core/install.php?langcode=en&profile=standard&id=1&op... StatusText: Internal Server Error ResponseText:

http://example.com/core/install.php?langcode=en&profile=standard&op=star...

This is on a Mac locally, but not using MAMP.

CommentFileSizeAuthor
#5 vdc-1895100-5.patch883 bytestim.plunkett
#4 Screen Shot 2013-01-23 at 8.16.23 AM.png65.26 KBmgifford
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented
Status: Active » Postponed (maintainer needs more info)

Can you provide some steps to reproduce?

ParisLiakos’s picture

ParisLiakos CreditAttribution: ParisLiakos commented
Status: Postponed (maintainer needs more info) » Active

i had this as well, just rm -rf your files/*

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented
Status: Active » Closed (cannot reproduce)

Ah, yes, a stale compiled container would do that.

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented
Status: Closed (cannot reproduce) » Active
FileSize
Screen Shot 2013-01-23 at 8.16.23 AM.png65.26 KB

I've done that, nixed the DB & tried it again. Twice.

Still I'm not able to install. @tim.plunkett - could this be stored somewhere else? I've got a git reset --hard several times now & am pulling the latest release. Puzzled why it's dying.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented
FileSize
vdc-1895100-5.patch883 bytes

#1668820-130: Concept, base class, and interface for Configurables (e.g., node types, image styles, vocabularies, views, etc) also found this bug, and wrote a patch!

But it doesn't explain WHAT the $entity is if its not an object.
Can you try this debugging patch and report what it prints out?

I'm still very unable to reproduce.

damiankloip’s picture

damiankloip CreditAttribution: damiankloip commented

I think you need to remove your files folder and maybe just rip out your settings.php file, and let drush make a new one. That should work. I think ....

alexrayu’s picture

alexrayu CreditAttribution: alexrayu commented

The entity is null if it's not an object, in this case (at least it was for me).

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented
Priority: Major » Normal
Issue tags: -php error

The array is supposed to be entity objects, keyed by their entity ID.
You can't see the entity ID from within the current loop, so I added a debug one.

I have installed both with drush and through the UI in multiple versions of PHP in both native LAMP and also MAMP. I'm convinced you have something stale causing this, and would not be able to reproduce on a truly clean install, as @damiankloip describes.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Active » Postponed (maintainer needs more info)

Doing this for now until we get more details.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

I just got this too after attempting to reinstall Drupal 8 over the top of an existing Drupal 8. Clearly dropping the database alone isn't sufficient. After tossing the files directory, Drupal could install normally again for me.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Category: bug » support
Status: Postponed (maintainer needs more info) » Fixed

Yeah, be warned that the sites/default/files/php directory now needs to be cleared out on site re-install. It contains a compiled version of the container or some such Symfony nonsense I don't totally understand.

So if that fixed it, I'm inclined to mark this a support request and fixed.

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented
Category: support » bug
Priority: Normal » Major
Status: Fixed » Active

You have to remove that directory with force.

In talking to @Lee Rowlands, he said that he's had to use the full path, and that even sudo rm sites/default/files/php/service_container/service_container_prod_.php/* does not work. He explained to me that it is so locked down because that is the compiled container and Drupal 8 now writes PHP to the file system.

I was able to remove it on my system by sudo rm -fr sites/default/files and then by just recreating the files directory.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Active » Postponed (maintainer needs more info)

No, it needs to be sites/default/files/php or, even more ideally, sites/default/files/*

Can you explain why this is a bug?

ParisLiakos’s picture

ParisLiakos CreditAttribution: ParisLiakos commented
Category: bug » support

The php folder is not writeable for your user, because it was created by apache...
Doing a simple rm wont kill it due to permissions
you need to use sudo and remove the whole folder..something like

sudo rm -rf sites/default/files/*
or just php folder

sudo rm -rf sites/default/files/php/*

Or, if you dont have sudo access write a php script that does this and call it from your browser, so apache itself will delete it.

This is not a bug. drupal cannot guess if you want to kill it and remove this file for you, you have to do this yourself, like clearing the database step

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented
Category: support » bug

I'd say it's a bug because for most folks they are going to be shocked that they have to have root access in order to re-install their Drupal system. It could be that it just needs to be better documented, but for most of us a "stale compiled container" is a new thing for most of us. If this is going to be a semi-common issue for folks who are starting to play with D8 then errors with ViewStorageController.php might need a bit more explanation.

It's the Symfony stuff that most of us might really grok after using it regularly for a few months that is going to be hard for the translation. That's why I think it's a bug.

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented
Category: bug » support

@rootatwc didn't mean to change Categories. I'm also not fixated on this being a bug, but rather making sure it's acknowledged as something that's going to need to be prepared for as folks get ready to take a look at it.

Might be good to offer that sample PHP script (not that it's hard), but we want folks to love D8! We want to bring along the D6 & D7 admins now and get them excited about moving up as soon as they can.

ParisLiakos’s picture

ParisLiakos CreditAttribution: ParisLiakos commented
Category: support » bug

Well, the way you put it, it is either a documentation task, or a new feature request against installation system, for it to be able to catch whether a container is broken and if yes, then remove it..
But anyway i wont play status wars anymore

ParisLiakos’s picture

ParisLiakos CreditAttribution: ParisLiakos commented
Title: PHP Fatal error: Call to a member function get() in ViewStorageController.php on line 26 » Document, that generated containers should be removed in case of drupal core reinstallation
Category: bug » task
Status: Postponed (maintainer needs more info) » Active

ugh..x-post..refactoring as task for now

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Title: Document, that generated containers should be removed in case of drupal core reinstallation » Document that generated containers should be removed in case of drupal core reinstallation
Component: install system » documentation

Switching components, removing a comma.

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented

Thanks all. I just want a nice experience for folks who start with D8. I'm looking back now on our D7 sites and just finding them very clunky now. So much great stuff has gotten into D8, I want folks to be excited about it.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented

OK... So where should we put this documentation?

IMO, it would be nice if in the install.php script, in the requirements phase, it would check to see if there are compiled generated containers (whatever they are) and either tell you how to remove them or just remove them if it can? I mean, it does this now for creating the files directory and other things... right?

If for some reason this isn't acceptable, then I guess we would need a patch to the install readme files (maybe both?), but it sure seems like rather than crashing, a polite message during the requirements phase of installation would be preferable. :)

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Title: Document that generated containers should be removed in case of drupal core reinstallation » Remove pre-existing compiled PHP code when re-installing Drupal core
Component: documentation » install system

I agree. The installer should be capable of doing so. It only needs to ensure that this only happens after the check whether there is a Drupal installation already. Retitling this issue.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented

I just created an issue summary for this issue, partly because I noticed that the "config" directory under sites/default/files can (I think?) cause problems too.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

Related: #1908310: Drupal without DB but with site config throws uninformative error

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented
Issue summary: View changes

Added issue summary

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

FWIW, I'm using this reinstall.php script in my D8 document root, in order to quickly and easily destroy and re-install my dev site.

Meanwhile, I'm no longer sure whether doing the proposed change here is a sane thing to do — the installer exists to create things, not to delete your data... ;)

At minimum, I guess we'd need a confirmation screen on which you'd explicitly have to confirm that your existing data is going to be deleted.

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented
Status: Active » Postponed (maintainer needs more info)

I think this has been resolved?

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented

Are you saying it's now possible to reinstall without removing sites/default/files?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

valthebald’s picture

valthebald
Location Sofia
CreditAttribution: valthebald as a volunteer commented
Priority: Major » Normal
Status: Postponed (maintainer needs more info) » Closed (works as designed)
Issue tags: +neworleans2016, +Triaged for D8 major current state

Performing the triage of this issue as part of the DrupalCon New Orleans.
This issue was definitely reproducable with earlier versions of 8.x core. However, the following steps:

  1. git checkout 8.1.x
  2. Install Drupal 8.1
  3. Drop Drupal database
  4. git checkout 8.2.x
  5. Install Drupal 8.2.x

went smoothly without deleting sites/default/files/*

Also, I don't see a reason why this could be a major issue, changing priority

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm at Acquia commented
Issue tags: -Triaged for D8 major current state

Thanks @valthebald! (Untagging since we decided it was not current nor major.)