Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Spawned from, and postponed on #22336: Move all core Drupal files under a /core folder to improve usability and upgrades.
One of the best summaries of the issue is #22336-73.
Basically, we want to discuss whether the sites
folder is the best way to store site specific settings, modules, themes etc.
If #22336 is accepted, we then want to look at how we structure the remaining folders in the webroot.
Comment | File | Size | Author |
---|---|---|---|
#13 | 760992-13.patch | 87.36 KB | naxoc |
#11 | folders-760992.patch | 3.43 KB | naxoc |
Comments
Comment #1
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedGrr. set the wrong links to previous issue:
Issue: #22336: Move all core Drupal files under a /core folder to improve usability and upgrades
Summary #22336-73: Move all core Drupal files under a /core folder to improve usability and upgrades
Comment #2
jstollerI 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.
Comment #3
Bojhan CreditAttribution: Bojhan commentedDoesn't seem like the best place to discuss this.. Especially with the recent move to /core
Comment #4
webchickHey, 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:
That's the default directory structure. settings.php ships with a setting:
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).
Comment #5
catchI 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.
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 :(
Comment #6
Bojhan CreditAttribution: Bojhan commentedSounds 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
Comment #7
catchYou'd have to edit settings.php to allow multisite, but it'd only be a one-line change.
Comment #8
naxoc CreditAttribution: naxoc commentedI 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.
Comment #9
naxoc CreditAttribution: naxoc commentedI guess the sites/default/files folder should also go in the root by default.
Comment #10
naxoc CreditAttribution: naxoc commentedHere 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?
Comment #11
naxoc CreditAttribution: naxoc commentedArgh. Now with patch
Comment #12
naxoc CreditAttribution: naxoc commentedOh, 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.
Comment #13
naxoc CreditAttribution: naxoc commentedHere 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:
sites/default/default.settings.php
to the drupal root.sites/all
and movesmodules
,themes
, andprofiles
to the drupal root.settings.php
in the drupal root.sites.php
present in the drupal root, it reads that and reacts to that just like in the old days in the sites folder.find_conf_path()
. This is either me not understanding what the original code did or a great simplification.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 asites.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.
Comment #14
klonosHow about:
1. we should either look for a sites.php file or a
$multisite
/$sites
variable/array in settings.php - not both2. 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)Comment #15
naxoc CreditAttribution: naxoc commented@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.
Comment #16
klonosGreat! 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?
Comment #17
sunHm. 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:
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...?
Comment #18
naxoc CreditAttribution: naxoc commentedYeah, 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.
Comment #18.0
naxoc CreditAttribution: naxoc commentedlink to issue in description