$confdir should be configurable

Which then begs the existential question, how can one modify where to find the configuration files if that is a configuration directive? :-)

Hm. Perhaps set a value in $_ENV from the htaccess file (which really can't go anywhere in the first place)? I guess this is something to look into after the freeze ends.

Like the sites/all issue, I'm going to assign this to myself so I can come back to it in 4 months when it's allowed again. :-) It sounds straightforward, unless someone has a better idea of where to set it than htaccess.

So yeah, I'm not actually going to get back to this after all. If someone else wants it, take it. If not, let's won't fix it to keep the issue queue clean.

I really like the idea of an ENV variable set from .htaccess. There are other ways to set ENV variables for non apache systems.

Which then begs the existential question, how can one modify where to find the configuration files if that is a configuration directive? :-)

What if we just agree on a location? For example, we always look for sites/sites.php and if it exists we include it. In sites.php, you would specify override $confdir with something like $confdir = '/var/nonweb/sites';

Hm. That would be another mark in favor of: #231298: Aliased multi-site support. I don't know off hand what would happen if you specified a non-relative path there.

Moving the entire confdir would mean that you can't put modules or themes in your site-specific directory and would have to use sites/all. I think that's an acceptable tradeoff, though. Hmmm...

Moving the entire confdir would mean that you can't put modules or themes in your site-specific directory and would have to use sites/all. I think that's an acceptable tradeoff, though.

That is going to be the question. For most single domain sites it would be fine as there is no difference between using sites/all/{modules|themes} and sites/example.com/{modules|themes}. In multisite however there could be the need for a distinction. I can think of the example possibly of a developer using a multisite install, with custom, paid for modules that they only want available for certain customers.

One thought is whether to change the location of the module and themes directories to say {modules|themes}/contrib and do away with the sites hierarchy all together. I know that a lot of work has been done recently to help new drupalers to understand where to put contrib modules and themes, but the directories in the drupal root are just too tempting for the who do not understand the drupal way of doing things. The other thought that comes to mind is to move all of the core modules and themes to either {modules/themes}/core or core/{modules|themes}. This could then allow site specific options in {modules|themes}/example.com which keeps the current flexibility.

Also, if the location of settings.php is moved, then we might need to rethink how we select which file to include. It seems silly to have to create potentially a large directory tree to hold a single file. Maybe the logic can be changed from looking for a example.com/settings.php file to looking for say settings-example.com.php or even example.com.php if we know that the only files that will be contained in the location will be settings files.

I also vote for finding a solution that does not rely on .htaccess files. Maybe use something like the sites.php file that was introduced in #231298: Aliased multi-site support, although if we are getting rid of the sites hierarchy then we need to move it to say DRUPAL_ROOT/sites.php.

Anyways, this is mostly a brain dump from a (newer) Drupal convert, so these kind of ideas may have already been discussed and discarded, but a fresh view can often be beneficial I think!

Soli Deo Gloria

I guess that's not relevant anymore for 7.x, but probably 'nice to have' for 8.x

following up here from #231298: Aliased multi-site support I don't see why the location of settings.php and the location of the site-specific modules and themes have to be the same - it would be better to have less magic and file scanning in favor of configuration.

#1757536: Move settings.php to /settings directory, fold sites.php into settings.php implicitly makes $conf_path configurable from within the root /settings.php file.