sites/default/files contains compiled PHP stuff, config and file uploads. We didn't want to burden people with creating more than one webserver writeable directory. My plan was that once #1856766: Convert file_public_path to the new settings system (make it not configurable via UI or YAML) is in to revisit the topic and move uploads one directory "in", ie. sites/default/files/uploads, sites/default/files/config, sites/default/files/php. David Rothstein has a similar but not identical proposal in #1967118-9: Figure out recommendations for Drupal 8 deployment challenges:

I think this is a big problem, and the default configuration doesn't make much sense to me for any site (small or large). Why should code, configuration, and user-uploaded files all live in the same place? This could cause security headaches too, since it encourages backups of all those things to be mixed together (even though you might care a lot more about the security of your code + configuration than you do about user-uploaded files, which are already public).

Would it be possible for the default configuration to look more like this:

sites/default/files => user-uploaded files
sites/default/config => configuration files
sites/default/code => compiled PHP code

Sites with multiple web servers would then be instructed to have the first two in a shared filesystem but the third one not shared.

Comments

Crell’s picture

Crell CreditAttribution: Crell commented

I'd be OK with either sites/default/files, sites/default/config, sites/default/code or with sites/default/files/upload, sites/default/files/config, sites/default/files/code.

The current setup definitely doesn't work, because it means you have files that should be checked into git (config) inside a directory that should not be checked into git (files). That totally can't fly. Either of the structures above (siblings of files, or all children of files) would resolve that problem.

chx’s picture

chx CreditAttribution: chx commented

The reason things got into files , we don't want people to bother with making three directories webserver writeable.

Crell’s picture

Crell CreditAttribution: Crell commented

Right. But making /sites/default/files writable, and then excluding /sites/default/files/content and /sites/default/files/php from git while leaving /sites/default/files/config in git would solve both problems. So +1 here.

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia commented

Building on #3, how about:
- sites/default/files/public
- sites/default/files/private
- sites/default/files/config
- sites/default/files/php

One flaw with the above is that it doesn't make 100% clear that "public" and "private" are content/uploaded files, whereas "config" and "php" aren't. Then again, the "public" files directory also contains css, js, and image caches, so what constitutes content/uploaded is blurry anyway.

Crell’s picture

Crell CreditAttribution: Crell commented

Bumping this, as I think it's going to be a serious problem if we don't fix it.

I'd be fine with #4. Then you can put just sites/default/files/config[_abcd] in git and git ignore the rest.

dman’s picture

dman CreditAttribution: dman commented

Happy to see thinking about this. If config belongs in git and the uploads don't then this is a big deal.

Crell’s picture

Crell CreditAttribution: Crell commented
Priority: Normal » Major
Issue summary: View changes

Bumping this to major and getting it back on people's radar. I think we should treat it as an RC blocker as well but I am not comfortable declaring that unilaterally. But I do think this is a release-blocking change.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

Existing sites will have publicly indexed links pointing to files in /files. It might be possible to do redirects in core, but I'd rather leave those where they are, and people can move themselves as part of a 6/7-8 migration if they want to.

There is already sites/default/files/config_ and sites/default/files/php. Also the config directories are configurable already.

So really the only difference in terms of location is sites/default/files/public and sites/default/files/private - to me that's a good change for the defaults.

The other spot is the hardcoding in PhpStorageFactory:

$configuration['directory'] = DRUPAL_ROOT . '/' . PublicStream::basePath() . '/php';

That could check settings first so it doesn't end up in sites/default/files/public/php

So this looks to me like a change that could happen in a minor release, no need for it to either block release or to be punted to 9.x.

Crell’s picture

Crell CreditAttribution: Crell at Palantir.net commented

catch: To clarify then, you're +1 on changing the defaults for public/private files as above, either now or in a point release (depending on when someone gets to it)?

Crell’s picture

Crell CreditAttribution: Crell as a volunteer commented
Version: 8.0.x-dev » 8.1.x-dev
Assigned: Unassigned » catch

Upping version, and getting it back on people's radar. Assigning to catch as there was an outstanding question for him.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.