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).

Comments

dries’s picture

The 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?

moshe weitzman’s picture

i'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.

singularo’s picture

I 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.

killes@www.drop.org’s picture

StatusFileSize
new7.23 KB

I#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.

killes@www.drop.org’s picture

We 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...

dopry’s picture

I 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.

kbahey’s picture

-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.

killes@www.drop.org’s picture

*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.

kbahey’s picture

Sorry. My mistake. No breakfast tea yet.

moshe weitzman’s picture

Status: Needs review » Needs work

+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

dopry’s picture

Category: bug » task

Setting as a task. Can we go ahead and get this in 4.8 with the additional folders in sites/default ?

sammys’s picture

Version: x.y.z » 5.0-beta1

http://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

Paul Natsuo Kishimoto’s picture

I've updated both this and 98824 that sammys referenced to 5.x-dev. One is a task and the other is a feature.

Paul Natsuo Kishimoto’s picture

Version: 5.0-beta1 » 5.x-dev

ACTUALLY updating.

pwolanin’s picture

why not site/all/files? - AFAIK, this is the current suggested best practice: http://drupal.org/node/53705

Crell’s picture

the 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. :-)

pwolanin’s picture

Yes, 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.

Crell’s picture

Ah, 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.

karldied’s picture

Thanks 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

pwolanin’s picture

I 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.

pwolanin’s picture

I 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.

pwolanin’s picture

I 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.

pwolanin’s picture

I 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.

karldied’s picture

Certainly /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.

Crell’s picture

karl, 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.)

karldied’s picture

I 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.

Crell’s picture

Yes. 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.

wim leers’s picture

Status: Needs work » Closed (duplicate)