Closed (duplicate)
Project:
Drupal core
Version:
5.x-dev
Component:
file system
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
23 May 2005 at 20:07 UTC
Updated:
3 Jul 2007 at 18:56 UTC
Jump to comment: Most recent file
Currently the defautl for the file storage directory is /files. This is a problrem if you should later decide to setup more than one site from the same source code. The attached page changes the default to be /sites/default/files (defautl is replaced by the site url if the default directory is renamed).
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | file-default_0.patch | 7.23 KB | killes@www.drop.org |
| file-default.patch | 4.98 KB | killes@www.drop.org |
Comments
Comment #1
dries commentedThe fact that the different
files-directories are potentially shared in a multi-site setup probably needs to be documented in the form description. I suggest you update the form descriptions too so the user understands why we are suggesting to store files in that particular directory.I guess it would be even better to _force_ files to be stored in the proper sub-directory of the
sites-directory. I see two problems with that though: legacy code will stop working, and URLs to static files become longer/uglier. It does get us a step closer to the proposed separating of 'system files' and 'local files'.Thoughts?
Comment #2
moshe weitzman commentedi'm curious how the bryght folks do this. they run a large mutli-site install.
you could work around this by setting a $conf['file_directory_path'] n a site's settings.php.
Comment #3
singularoI discovered this with the image module, and worked around it by using files/www.whatever.com in the file system path setting, but I think it would be better to have seperate "files" directories for each site.
Comment #4
killes@www.drop.org commentedI#ve updated the patch and added some blurb to the general file setting path. I agree with Dries that we should force the people to use a file patch that contains their domain name. Not sur how to do that, though.
Comment #5
killes@www.drop.org commentedWe could of course hardcode the variable to
$conf['file_directory_path'] = conf_init() .'/files';
in settings.php and remove the admin selectable download directories alltogether. Problem is that /sites would have to be webserver writable which might not be desirable. Also, we would need a way to protect private downloads...
Comment #6
dopry commentedI don't like the hardcoded idea, but I do like the idea of a recommended default being in the sites folder...
Mainly because it tied into some ideas I had about easing upgrades and managing contrib/custom modules in http://drupal.org/node/29180.
I don't think the permissions situation should be too much of a problem as long as sites is traversable by the webserver only the files folder has to be writable, and if its writeable you can control directory access from apache through and .htaccess file written by drupal, which would solve some issues for changing from private to public files vice versa as long as drupal understood that if files are private /files takes on a new meaning and should become a callback to check permissions and retrieve the file. It would probably be an approach that only worked with cleanurls, but it seems to be half the battle.
Then again I could be wrong, I really don't have a clue how drupal's file management works anyway.
Comment #7
kbahey commented-1 for hardcoding this anywhere.
A long time ago (since 4.3 or so), I started running multi-site Drupal, with several domains off of one codebase. This was a major cause for my decision to go with Drupal.
I set the files variable to "files/sitename" for each site to separate content for each site.
If you want it to be obscure and not easily changed then add the parameter to the settings.php where it can be changed by advanced users and not casual ones.
But in all cases, it must still be configurable. Hard coding is NEVER good.
Comment #8
killes@www.drop.org commented*gah* read what I've written: "hardcode in settings.php" this of course means that the admin can change it. The current situation is not a good one as every user with the appropriate permissions can screw things up.
Comment #9
kbahey commentedSorry. My mistake. No breakfast tea yet.
Comment #10
moshe weitzman commented+1 for
$conf['file_directory_path'] = conf_init() .'/files';. Settings to 'needs work' since no such patch has appeared here yet.RELATED THOUGHT
I'd like to ship with the following directories already created and with a README.txt inside of them. This will encourage admins to keep all their custom stuff in its own hierarchy. Great for backups.
sites/default/files
sites/default/themes
sites/default/modules
Comment #11
dopry commentedSetting as a task. Can we go ahead and get this in 4.8 with the additional folders in sites/default ?
Comment #12
sammys commentedhttp://drupal.org/node/98824 has a very similar thing, but the implementation (including patch) is slightly different. Not sure which one to blow off as a duplicate at this stage. I'll go with whatever.
--
Sammy Spets
Synerger
http://synerger.com
Comment #13
Paul Natsuo Kishimoto commentedI've updated both this and 98824 that sammys referenced to 5.x-dev. One is a task and the other is a feature.
Comment #14
Paul Natsuo Kishimoto commentedACTUALLY updating.
Comment #15
pwolanin commentedwhy not
site/all/files? - AFAIK, this is the current suggested best practice: http://drupal.org/node/53705Comment #16
Crell commentedthe sites/all directory is just for modules and themes that you want shared across multi-sites. It doesn't correspond to any specific site, which is why there's no settings.php file. Putting the default files directory there would only make sense if you wanted all uploaded files from all sites to be shared. That's content, not code. Sharing content between sites is a messy business. :-)
Comment #17
pwolanin commentedYes, I realize it's not what you want this for multi-site. I'm coming into this a bit late, so i thought the idea was simply to get /files out of the drupal root. then, if you need to transition to multi-sites, you would obviously need to move the files directory per website. The same is true if you put it in /sites/default/files, right? Or, is the idea that you would (naturally?) copy settings.php and /files to /sites/sitename?
Also, I want to make sure that http://drupal.org/node/53705 is correct.
Comment #18
Crell commentedAh, it looks like that page is not correct. I've submitted a Documentation issue to correct it.
Putting the default files directory in /sites/default/files makes sense to me. It gets things out of Drupal root and is compatible with multi-site. Moving that setting to settings.php also makes sense, but may not be kosher now that D5 is in RC freeze. There's also the issue of the user needing to still create it and set its permissions accordingly. I leave that to Dries and Co. to decide. At minimum, setting the default value of the variable to sites/default/files is probably a good idea and RC-safe, since it's not a translatable string.
Comment #19
karldied commentedThanks for submitting the doc issue: Incorrect /sites/all documentation
http://drupal.org/node/53705 is updated: it no longer has "/sites/all/files" and has instead "/sites/default/files"
See also /sites directory setup for initial (single-site) installation recommendations, to see if that's what is intended (tracked under /node/103915)
I'm not sure if Use of sites/default/files as the default files directory isn't the same issue as this one. At the minimum, it is closely related.
Comment: Some common files are kept in /sites/all while others are kept in /sites/default. This creates confusion because it is not obvious (without reading the manual) which common items go where. The only reason I can see for having them separate is that you can copy /sites/default to /sites/www.example2.com to easily create a second site. I really think it would be better to have these two locations for common files combined!
-karldied
Comment #20
pwolanin commentedI think the difference is that /sites/all will be shared among all sites in a multi-site, while sites/default or sites/example.com will only be accessed by a single site.
Comment #21
pwolanin commentedI think the difference is that /sites/all will be shared among all sites in a multi-site, while sites/default or sites/example.com will only be accessed by a single site.
Comment #22
pwolanin commentedI think the difference is that /sites/all will be shared among all sites in a multi-site, while sites/default or sites/example.com will only be accessed by a single site.
Comment #23
pwolanin commentedI think the difference is that /sites/all will be shared among all sites in a multi-site, while sites/default or sites/example.com will only be accessed by a single site.
Comment #24
karldied commentedCertainly /sites/example.com is site-specific. But if it doesn't exist, including for a multi-site setup with www.example1.com and www.example2.com, the domains will go to /sites/default to find settings.php and /files.
But /sites/all is just another common location, this time for /modules and /themes. The distinction is that the domain _always_ looks for /sites/common/modules and /sites/common/themes, but _only_ looks for /sites/common/settings.php and /sites/common/files if they are not to be found in /sites/example.com
Let me try to express this another way: /files and /settings.php are searched using an OR logical method (in /sites/example.com OR /sites/common); /modules and /themes are searched using an AND logical operator (drupal will use modules in /sites/example.com AND /sites/common/modules). Different common directories could be dictated if the ability to scan elements using OR logical method requires directories exclusive from those scanned using AND; but I seriously doubt the code has this limitation.
As far as I can tell (with only my end-user expertise), these two common locations are logically (mathematically so) duplicative, and therefore unnecessary and confusing.
Comment #25
Crell commentedkarl, there is no such thing as a common files directory or common settings.php. There is a "Default fallback" site, which has a files directory and a settings.php file, but default fallback != common. A common settings.php file doesn't make any sense, nor, frankly, does a common files directory.
There is one and only one common directory, sites/all/modules. sites/default/modules is not common in any way. They serve two different purposes.
(Actually there's also the top-level /modules directory, but the whole point of sites/all is to never ever touch that directory unless you're upgrading Core.)
Comment #26
karldied commentedI should not have used /common to try to refer to the /default and /all names, and agree 'common' does not describe the fallback (OR) use for the /default directory. 'base' would probably have been a better selection than 'common'.
Moving on, does /sites/default/modules ever have a legitimate existence? That is the concept I still haven't captured. Thanks.
Comment #27
Crell commentedYes. If you visit example.com, and there is no sites/example.com/, then Drupal falls back to sites/default/ as the config directory. We're now well off-topic for this issue, though. Please continue on the support mailing list if you still have questions.
Comment #28
wim leersDuplicate of http://drupal.org/node/98824.