Assume there are two site directories A and B.
The request resolution will identify A as the first candidate, and then B.
(e.g. A = sites/foo, B = sites/default)
A has no settings.php, but B has.
On core/install.php, findSitePath() will stop at A and attempt an install.
On index.php, if A is not installed yet, findSitePath() will move on to B and boot that.
I wonder if this behavior is intended.
IMO it would feel more consistent to let findSitePath() always stop at the first existing directory, and then simply fail or redirect to install.php, if there is no settings.php and it is not an installation request.
Or seen from a different angle:
Assume you have
- sites/example.com WITHOUT a settings.php
- sites/default WITH settings.php
If you visit http://example.com/whatever, it will show the site from sites/default.
If you visit http://example.com/core/install.php, it will attempt to install in sites/example.com.
IMO this is inconsistent and confusing.
It MIGHT also be dangerous, not sure.
Proposed solution:
DrupalKernel::findSitePath() should always stop at the first existing directory it finds, no matter if there is a settings.php.
Then if settings.php is missing, it should either show an error page or redirect to core/install.php.
This will force people to not leave empty site directories around, that could be hijacked for unintended site installation.
This will allow us to eliminate the $require_settings parameter from DrupalKernel::findSitePath(), which is great if we continue to refactor the kernel and bootstrap.