[drupal-devel] [bug] Change default for files directory

[dopry]

Issue status update for 
http://drupal.org/node/23467
Post a follow up: 
http://drupal.org/project/comments/add/23467

 Project:      Drupal
 Version:      cvs
 Component:    file system
 Category:     bug reports
 Priority:     normal
 Assigned to:  killes at www.drop.org
 Reported by:  killes at www.drop.org
 Updated by:   dopry
 Status:       patch (code needs review)

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.




dopry



Previous comments:
------------------------------------------------------------------------

Mon, 23 May 2005 20:07:40 +0000 : killes at www.drop.org

Attachment: http://drupal.org/files/issues/file-default.patch (4.98 KB)

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




------------------------------------------------------------------------

Tue, 24 May 2005 20:22:17 +0000 : Dries

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?




------------------------------------------------------------------------

Wed, 25 May 2005 02:47:45 +0000 : moshe weitzman

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.




------------------------------------------------------------------------

Wed, 25 May 2005 06:55:39 +0000 : singularo

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.




------------------------------------------------------------------------

Mon, 01 Aug 2005 02:16:01 +0000 : killes at www.drop.org

Attachment: http://drupal.org/files/issues/file-default_0.patch (7.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.




------------------------------------------------------------------------

Fri, 19 Aug 2005 22:01:41 +0000 : killes at www.drop.org

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