Installation Failure on case insensitive file systems

I am having this same issue: Mac - PHP 5.5.20 & Apache/2.4.10

I just went back and tried drupal 8.0.0-beta7 and I am not getting this issue, so it seems to be a problem with drupal 8.0.0-beta9.

I'm running into the same thing against 8.0.x HEAD on OSX 10.10, Apache 2.4.10, PHP 5.5.19. Git bisect points to commit 95fe74d57108faea52df0f1f16277a4c4732cbb0 as the culprit, trying to suss through the autoload changes made in that commit.

It appears the redirect from / to /core/install.php is working fine, but that's where it dies. Apparently drush-based installs just work.

OK, digging a bit more, looks like the same bootstrap.inc file is included using require_once and include_once everywhere, but the paths used to include it are different. Is this possibly causing a problem under certain configurations of PHP?

./core/includes/common.inc:8: * a cached page are instead located in bootstrap.inc.
./core/includes/install.core.inc:299:  require_once __DIR__ . '/bootstrap.inc';
./core/install.php:22:// yet available. It is defined in bootstrap.inc, but it is not possible to
./core/lib/Drupal/Core/DrupalKernel.php:219:    require_once $core_root . '/includes/bootstrap.inc';
./core/lib/Drupal/Core/EventSubscriber/DefaultExceptionSubscriber.php:37:   * One of the error level constants defined in bootstrap.inc.
./core/lib/Drupal/Core/Test/TestKernel.php:23:    require_once __DIR__ . '/../../../../includes/bootstrap.inc';
./core/modules/update/update.module:616:    && file_exists("$directory/$project/core/includes/bootstrap.inc")
./core/rebuild.php:28:require_once __DIR__ . '/includes/bootstrap.inc';
./core/scripts/dump-database-d6.sh:27:include_once './includes/bootstrap.inc';
./core/scripts/dump-database-d7.sh:28:include_once './includes/bootstrap.inc';
./core/scripts/generate-d6-content.sh:28:include_once './includes/bootstrap.inc';
./core/scripts/generate-d7-content.sh:30:include_once './includes/bootstrap.inc';
./core/scripts/migrate-dump-d6.sh:33:require_once __DIR__ . '/../includes/bootstrap.inc';
./core/scripts/rebuild_token_calculator.sh:19:require_once __DIR__ . '/../includes/bootstrap.inc';
./core/scripts/update-countries.sh:36:// Drupal bootstrap of core/includes/bootstrap.inc (where t() is declared).
./included.log:21:  19 => '/Users/rbates/sites/d8/public_html/core/includes/bootstrap.inc',

I am using Drupal 8 - Beta10 under MAMP (non-pro) on OSX and ran into this issue. To host multiple sites I am manually adding information to my apache vhosts file under MAMP and as well to the hosts file under the OS. Here is something I noticed:

My error says:

PHP Fatal error: Cannot redeclare conf_path() (previously declared in /Users/steve/Documents/Projects/MAMP-sites/epd8.local/core/includes/bootstrap.inc:142) in /Users/steve/Documents/projects/MAMP-sites/epd8.local/core/includes/bootstrap.inc on line 159

Notice what I have bolded above. The word "Project" in the first path has a capital "P" while the second path has a lowercase "p".

My physical path used a lowercase "p"

My apache httpd-vhosts.conf file uses an uppercase "P" when referencing the DocumentRoot and the Directory path.

Editing the physical path to match the path in the vhost file solved the problem. I wonder if the function conf_path (or whatever might replace that function if it is, in fact, being deprecated) could be modified to handle that situation?

Attached is a patch that should fix the issue for everyone. I'm going to mark this as Major since it prevented me from installing Drupal. Not sure what conditions cause the error and why it doesn't always happen for everyone, but this should fix it for everyone.

It looks like this error is specific to Mac OS X. I'm using the built-in Apache/PHP, but it looks like everyone on this thread is using either built-in Apache/PHP or they are using MAMP.

It looks like the work-around is to install with drush #2.

conf_path() is being removed #2384675: Deprecate conf_path(). Can an affected person please test against 8.0.x now?

#7,

The problem still need to be resolved because the path to the autoloader is wrong (see patch in #5)

I'm on the latest head and I'm still getting the following error:

 Fatal error: Cannot redeclare conf_path() (previously declared in core/includes/bootstrap.inc:143) in core/includes/bootstrap.inc on line 160

But like I've said, this issue actually has nothing to do with conf_path() or the error that is being thrown, it has to do with an incorrect require path.

Even if conf_path() is removed this error will just report a different function until the patch is committed.

The change in syntax was introduced in #2406681: Add an autoload.php in the repo root to control the autoloader of front controllers

While I don't see anything technically wrong with this patch, I'm having trouble figuring out how the autoloader is including bootstrap.inc. Is this error the same one that's still happening?

#14,

Before Patch
Error

 Fatal error: Cannot redeclare conf_path() (previously declared in /Users/david/Sites/test/web/core/includes/bootstrap.inc:143) in /Users/david/sites/test/web/core/includes/bootstrap.inc on line 160

Path realpath('autoload.php');

/Users/david/sites/test/web/autoload.php

After Patch
No Error
Path realpath(__DIR__ . '/../autoload.php');

/Users/david/Sites/test/web/autoload.php

At least on the system I am using require_once 'autoload.php' != require_once __DIR__ . '/../autoload.php'

I'm not sure why fixing this in this place would resolve the error, but it does. I admit that this might be a Apache or PHP configuration problem, but I'm not sure what it is.

So installer.php says this:

// Change the directory to the Drupal root.
chdir('..');

And then the patch does this:

+++ b/core/install.php
@@ -27,6 +27,6 @@
 // Start the installer.
-$class_loader = require_once 'autoload.php';
+$class_loader = require_once __DIR__ . '/../autoload.php';
 require_once __DIR__ . '/includes/install.core.inc';

So basically we have three things:

• The inline comment is wrong (not changing to Drupal root).
• We cd to core/.
• We get the classloader by specifying a relative path outside of core/.

So it's not clear which of these steps is important for installation to work, and which is the result of a loooooong patch-based development cycle. :-)

I understand what the change does, just I don't have a case insensitive filesystem to test this on so I'm trying to understand how it fixes the problem.

From what I can tell only 2 places that bootstrap gets included during install are in install.core.inc and in DrupalKernel.php. This matches why we see in #3.

One uses:

require_once __DIR__ . '/bootstrap.inc';

the other:

    // Include our bootstrap file.
    $core_root = dirname(dirname(dirname(__DIR__)));
    require_once $core_root . '/includes/bootstrap.inc';

So if we assume __DIR__ resolves correctly, both are built from __DIR__ and should have nothing to do with the autoloader. So how does this change their behavior? :-/

#16,

You need to be cd'd into core for many other reasons than loading the autoloader. So the inline comment is not wrong.

If you don't have a system to reproduce the problem, please don't mark it as "Needs Work" when there is no work to be done. Before the patch, install is borken, after the patch, install is fixed. This patch also passes all other automated tests, and it reverts an early unrelated, unnecessary, overlooked change.

#17,

+++ b/core/install.php
@@ -27,6 +27,6 @@
-$class_loader = require_once 'autoload.php';

I can only assume that because this does not have __DIR__, that that is what messed it up. If you look at #2406681: Add an autoload.php in the repo root to control the autoloader of front controllers you'll see there is a __DIR__ before it was removed. Drupal worked before that patch, it broke after it.

If you don't have a system to reproduce the problem, please don't mark it as "Needs Work" when there is no work to be done.

Well, you see, in my opinion, there was work to be done, so therefore, it needed work.

Whether my opinion is correct or not is another story.

As it turns out, yah, I'm not so correct. __DIR__ is not relative to chdir(), and I must have been thinking install.php was under /scripts for some reason.

I'd try to repro but the OP lacks specifics on how to do that. I have a Mac and use MAMP, but I install using install.php all the time with no ill effects.

I can report that install completed under MAMP with PHP 5.5.10, with the patch.

I run on OSX with default Apache running. Using homebrew to install later version of php.
I ran into this issue as well. I used the patch and now it works.

PHP 5.5.22 (cli) (built: Apr 3 2015 11:30:16)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

Server version: Apache/2.4.10 (Unix)
Server built: May 19 2015 09:36:36

Run this as part of apache setup:

Options FollowSymLinks Indexes MultiViews
AllowOverride All
Require local
#Require all granted


ServerName default.site
VirtualDocumentRoot /Users/myname/Sites/%-2/docroot
UseCanonicalName Off
ErrorLog /private/var/log/apache2/sites-error_log

I too can confirm that you are unable to run /install.php on Drupal 8 RC2 when running on Mac OS. The included patch indeed did solve the problem.

Configuration
Mac OS 10.11.1
PHP 5.5.29
Apache 2.4.16

Same problem on RC3, this patch solves it.
Do you know if this patch will be included in the final release ?

Kwadz,

Please change the status to "Reviewed & Tested by the Community" (RTBC). I still can't explain why this fixes the issue, but it seems to fix it without any side effects.

PHP docs say this:

Files are included based on the file path given or, if none is given, the include_path specified. If the file isn't found in the include_path, include will finally check in the calling script's own directory and the current working directory before failing.

So we're benefitting from the current working directory having an autoload.php file in it. But that's a brittle anti-pattern, since other search paths could have other files named autoload.php which might have different purposes.

Let's get rid of the magic and make an explicit root path, based on cwd. This should mean that whatever case the path elements may be, they would be stored in the path string.

Here's a patch to do that.

Unfortunately I can't repro the problem so someone will have to manually test.

Ran into this problem with RC4, working with a fresh version of latest XAMPP (5.6.14). Patch from #25 worked for me. Reasoning and code seem sound.

Configuration
Drupal 8.0.0-rc4
Mac OS 10.8.5
PHP 5.6.14
Apache 2.4.17

This is still a problem with Drupal 8.02 release. I get the error when installing in /Applications/MAMP/htdocs/drupal8/
I moved the installation to the root directory / and it works fine now.

OS X 10.9.5
Drupal 8.0.2
Php 5.5.10
Running in a local test environment MAMP 3.0.3 free version.

#27,

Could you try moving it back to the original location and applying the patch? If the patch works for you, could you mark this issue RTBC?

This fixed the issue for me when trying to reinstall through the UI on my Mac OS X machines.

Committed/pushed to 8.1.x and cherry-picked to 8.0.x. Thanks!