Where should site specific modules, themes and settings be kept?

I just read through all of the comments to date on #22336: Move all core Drupal files under a /core folder to improve usability and upgrades. I am against moving site files into webroot. To me, that just complicates things. Then the core/ directory will get lost in a sea of other stuff, reducing the benefits of having it in the first place.

All of my issues as a Drupal newbie (at least as they related to file paths) would have been solved if webroot contained two directories: core/ and sites/. That provides a very clear distinction between the core system (i.e. things I shouldn't touch) and the place where my websites go. All in all, this seems very intuitive.

I also don't think we need to hide the fact that Drupal supports multi-sites. So having sites/all/ and sites/default/ directories makes perfect sense. Again, moving sites/all/* into the root of sites/ would just cause confusion by mixing directories like themes/ and modules/ with directories for individual sites. I understand that this keeps the important site files deeper in the hierarchy, but that hierarchy exists for a reason. It makes it easy to find what you need, even if doing so requires a couple extra clicks.

If clarity is really what you're after, then I don't think changing the file structure is the key. Instead, I'd recommend adding a file at sites/README--about_sites.txt. This, more than anything else, would help newcomers to Drupal in getting their sites set up. This readme file could explain exactly what goes where in the sites directory, including for multi-site installations. It would duplicate much of the documentation in sites/default/default.settings.php, but that's a good thing. Newbies don't know to look in sites/default/default.settings.php for instructions. I sure didn't.

Doesn't seem like the best place to discuss this.. Especially with the recent move to /core

Hey, I was looking for this issue!

I think this is a great idea, personally. It would use the behaviour we currently don't like in Drupal 7 and below ("Oh, look! Here's a modules folder! Let me stick my modules in there!") to our learnability advantage. These ideas I'm pretty sure were already quicksketch's, but putting them here cos I couldn't find them documented anywhere else.

Picture the following:

- core/ - SLAP! Core's stuff. Do not touch this. Just trash the whole folder and replace it upon upgrade.
- modules/ - *My* modules! (equivalent to today's sites/all/modules)
- profiles/ - *My* profiles! (equivalent to today's /profiles)
- themes/ - *My* themes! (equivalent to today's sites/all/themes)
- .htaccess - Because this has to go here.
- README.txt - Because OMGWTFBBQ.
- example.gitignore - Because this has to go here.
- index.php - Because this has to go here.
- robots.txt - Because this has to go here.
- settings.php - *My* settings.php! (equivalent to sites/default/settings.php)
- web.config - Because this has to go here.

That's the default directory structure. settings.php ships with a setting:

$multisite = FALSE;

If you want to use multisite, then you change that variable to TRUE and add a "sites/" folder to the mix as well, which operates on the standard lookup pattern in 7.x and below. The difference is it doesn't do the 99% case thing *last* after it's already eliminated the other 30 possible options of where the $conf_path could be (Rasmus chided us for this in Szeged in 2008 and we still haven't fixed it).

I think the concern about the core directory getting lost is a bit overblown. We're only talking about 4 directories here in the default case, 5 if you're using multisite, and *possibly* an extra one if we chose to move docs like CHANGELOG.txt into a "docs/" directory for security hardening (separate issue plz).

I think this is definitely worth looking at. If we could guarantee settings.php is always available in always the same place, then that might fix one chicken/egg issue with the class loader too.

The difference is it doesn't do the 99% case thing *last* after it's already eliminated the other 30 possible options of where the $conf_path could be (Rasmus chided us for this in Szeged in 2008 and we still haven't fixed it).

It's fixed by #1055856: Optimize settings.php discovery and #1055862: Require sites.php to opt-in for multi-site support/functionality, the latter we don't need if we require settings.php (in fact we can completely remove sites.php and just use the root settings.php to hold the $sites array), the former is dying for a review :(

Sounds good to me, does that mean that out of the box you can't do multi-site setups? It will be pretty similiair to how you make your site multi-site with wordpress

You'd have to edit settings.php to allow multisite, but it'd only be a one-line change.

I also really like the idea that modules/ and themes/ are in the root. I think everybody I have ever tried to teach installing modules would put them there anyway.

I guess the sites/default/files folder should also go in the root by default.

Here is the easy part. All I did was move the folders in sites/all to the root. It seems to work with both themes, modules, and profiles but I am sure it does create all kinds of problems I havent found yet.

I have also still to clean up all references to sites/all.

I wonder if moving the settings file to root should be its own issue?

Argh. Now with patch

Oh, the folder stuff is already going on over here #1724252: Allow and encourage top-level directories instead of /sites/all/* directories

Let's keep this issue open for the settings.php stuff.

Here is a patch that uses a settings file in the root folder. I applied the patch from #1724252: Allow and encourage top-level directories instead of /sites/all/* directories before I started work on this because it kinda lays the foundation for not using the sites all folder.

I can see that stuff similar to the this patch already has been discussed and worked on in #1055862: Require sites.php to opt-in for multi-site support/functionality.

This patch is still very rough and naive. Documentation I haven't even touched yet because I would like some feedback before that (rather large) task starts.

Here is what the patch does:

• Moves sites/default/default.settings.php to the drupal root.
• Kills sites/all and moves modules, themes, and profiles to the drupal root.
• Assumes that the default install uses a settings.php in the drupal root.
• If there is a sites.php present in the drupal root, it reads that and reacts to that just like in the old days in the sites folder.
• Simplifies the code in find_conf_path(). This is either me not understanding what the original code did or a great simplification.
• webchick suggested a variable in settings.php that says multisite TRUE/FALSE. I tried working with that concept but I kept running into the chicken and the egg problem so the existence of a sites.php file is used as that in the patch.

I have tested this with both multisite and without. I have run almost all of the tests and they pass, but I can't run the Bootstrap tests right now for some reason (see #1756348: PageCacheTest fails).

I took extra care manually testing the installers for both multisite and not, and they seem to work for the testing I have done.

How about:

1. we should either look for a sites.php file or a $multisite/$sites variable/array in settings.php - not both
2. having a sites.php would imply $multisite = TRUE;
3. instead of having a $multisite variable in settings.php *and* a $sites array, have only $sites and that would imply $multisite = TRUE;
4. either keep $sites in sites.php (for clarity/distinction/findability) or in settings.php (for simplicity - if so, then ditch sites.php and #1055862: Require sites.php to opt-in for multi-site support/functionality)

@klonos I agree. The patch in #13 assumes no multisite unless there is a sites.php. $sites lives in sites.php. There is no multisite config in settings.php.

Great! So, how is this different from #1055862: Require sites.php to opt-in for multi-site support/functionality? Also this issue's title is in the form of a question while it is set to a feature request. What are we trying to achieve here? I can only test-review the patch in #13. What should I test?

Hm. This patch is unfortunately trying to do too many things in one fell swoop... :-/

I think we should focus on #1055862: Require sites.php to opt-in for multi-site support/functionality first to get that out of the way.

Second, #1724252: Allow and encourage top-level directories instead of /sites/all/* directories already deals with ditching sites/all/* in favor of top-level directories, so let's keep the changes for that in there.

On the rest:

1. All paths in Drupal never contain a trailing slash, so the change to conf_path() is bogus.
2. The clean-up to conf_path() essentially removes the site folder discovery that allows to use e.g. 'sites/example.com' as a wildcard/catch-all for all subdomains of example.com, and I believe we want to keep that, so that looks bogus to me as well.

What essentially remains for this issue is the topic of moving settings.php to the top-level directory. However, it might make sense to create a dedicated issue to have and concentrate on that discussion...?

Yeah, this kinda is the omni-patch. Lets split it up. I made another issue on the settings php in #1757536: Move settings.php to /settings directory, fold sites.php into settings.php

Regarding the trailing slash we can most definitely find a better way.

I didn't think of wildcard domains at all. That would explain the great simplification :)

Marking as duplicate.

link to issue in description