Files directory on installation usability fix not quite usable. ; )
Here's a usability report from one of our GHOP students: http://ijailbreak.com/drupal.html (please post feedback to http://drupal.org/node/197219#comment-652618). He interviews three test subjects: his mom, his brother, and his Dad. In it, he points out that all three of his test subjects got totally blocked at this error and needed him to step in and fix it in order for them to continue. This is the *second* page of the installation. If we are losing people before they even get Drupal installed, we are screwed. I realize the argument against including a files directory by default is that Mac OS does this insane behaviour of overwriting the contents of "files" with another directory of the same name, so there's a chance of completely blowing away someone's files directory. So as far as I can see, we're left with a couple of options: - Revert the existing behaviour, which at least allows mere mortals to get Drupal installed, even if it's a somewhat annoying thing to deal with later. - Include the blank files directory anyway, and trust that people are either reading upgrade instructions, or not running production websites off of a Mac OSX desktop/laptop. Thoughts? -Angie
put in a files directory with a readme.txt On Dec 8, 2007 1:48 PM, Angela Byron <drupal-devel@webchick.net> wrote:
Here's a usability report from one of our GHOP students: http://ijailbreak.com/drupal.html (please post feedback to http://drupal.org/node/197219#comment-652618). He interviews three test subjects: his mom, his brother, and his Dad.
In it, he points out that all three of his test subjects got totally blocked at this error and needed him to step in and fix it in order for them to continue. This is the *second* page of the installation. If we are losing people before they even get Drupal installed, we are screwed.
I realize the argument against including a files directory by default is that Mac OS does this insane behaviour of overwriting the contents of "files" with another directory of the same name, so there's a chance of completely blowing away someone's files directory. So as far as I can see, we're left with a couple of options:
- Revert the existing behaviour, which at least allows mere mortals to get Drupal installed, even if it's a somewhat annoying thing to deal with later. - Include the blank files directory anyway, and trust that people are either reading upgrade instructions, or not running production websites off of a Mac OSX desktop/laptop.
Thoughts?
-Angie
An issue was created and handled for this already: http://drupal.org/node/191310 Wim Angela Byron wrote:
Here's a usability report from one of our GHOP students: http://ijailbreak.com/drupal.html (please post feedback to http://drupal.org/node/197219#comment-652618). He interviews three test subjects: his mom, his brother, and his Dad.
In it, he points out that all three of his test subjects got totally blocked at this error and needed him to step in and fix it in order for them to continue. This is the *second* page of the installation. If we are losing people before they even get Drupal installed, we are screwed.
I realize the argument against including a files directory by default is that Mac OS does this insane behaviour of overwriting the contents of "files" with another directory of the same name, so there's a chance of completely blowing away someone's files directory. So as far as I can see, we're left with a couple of options:
- Revert the existing behaviour, which at least allows mere mortals to get Drupal installed, even if it's a somewhat annoying thing to deal with later. - Include the blank files directory anyway, and trust that people are either reading upgrade instructions, or not running production websites off of a Mac OSX desktop/laptop.
Thoughts?
-Angie
Wim Mostrey wrote:
An issue was created and handled for this already: http://drupal.org/node/191310
Wim
Right. That issue caused the problem in the first place, hence my report. ;) Documentation in INSTALL.txt about this is obviously nice to have, but is not a replacement for making the installation actually completable for new people. But through that, I found http://drupal.org/node/194369 and that seems to be where this reply is more appropriate, so I'll go post over there. Thanks! -Angie
Why not just require write permission just as we require write permission of settings.php (unless you do it manually). Then use the install script to write a files directory. That way there is not a file directory in the distro and won't cause any problems with copying files over for upgrades. -- Alan Doucette Koi Technology, LLC www.KoiTech.net
Because then Drupal requires write access to the entire drupal directory where all code is stored. That's a big red neon "hack me" sign. On Saturday 08 December 2007, DragonWize wrote:
Why not just require write permission just as we require write permission of settings.php (unless you do it manually). Then use the install script to write a files directory. That way there is not a file directory in the distro and won't cause any problems with copying files over for upgrades.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
I don't see it as any different as the big red neon hack me sign on the file that contains your database username and password. We still do that as a convenience and then warn the user to set the permissions back. And it is not like more work, the user is already setting permissions to write then back it would just be one more done the same way, unless you do it all manually which is always an option. Alan On 12/8/07, Larry Garfield <larry@garfieldtech.com> wrote:
Because then Drupal requires write access to the entire drupal directory where all code is stored. That's a big red neon "hack me" sign.
On Saturday 08 December 2007, DragonWize wrote:
Why not just require write permission just as we require write permission of settings.php (unless you do it manually). Then use the install script to write a files directory. That way there is not a file directory in the distro and won't cause any problems with copying files over for upgrades.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
On a second note I think that the default install of the files directory should be in sites/default just as the default settings.php is. This would also making it easier just to give write permissions to that directory and the files in it, and that won't give you the full write access to all drupal files. This is not to say that you should be not be able to pick your files directory path just as you normally can, I just think the default place should be sites/default/files instead of files Alan On 12/8/07, DragonWize <dragonwize@gmail.com> wrote:
I don't see it as any different as the big red neon hack me sign on the file that contains your database username and password.
We still do that as a convenience and then warn the user to set the permissions back. And it is not like more work, the user is already setting permissions to write then back it would just be one more done the same way, unless you do it all manually which is always an option.
Alan
On 12/8/07, Larry Garfield <larry@garfieldtech.com> wrote:
Because then Drupal requires write access to the entire drupal directory where all code is stored. That's a big red neon "hack me" sign.
On Saturday 08 December 2007, DragonWize wrote:
Why not just require write permission just as we require write permission of settings.php (unless you do it manually). Then use the install script to write a files directory. That way there is not a file directory in the distro and won't cause any problems with copying files over for upgrades.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 DragonWize schrieb:
I don't see it as any different as the big red neon hack me sign on the file that contains your database username and password.
We still do that as a convenience and then warn the user to set the permissions back. And it is not like more work, the user is already setting permissions to write then back it would just be one more done the same way, unless you do it all manually which is always an option.
This could all be solved by moving the default files directory into the sites directory. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHWw4nfg6TFvELooQRAhstAJ9rjhCCH5utLRLFxqBw1AGVAC6uMQCgy/Px FGfMZSMQM7C3DLGAA6slftY= =oNE/ -----END PGP SIGNATURE-----
Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
This could all be solved by moving the default files directory into the sites directory.
And this is a solution that has other consequences, like being logical for multisite installations.
Gerhard Killesreiter wrote:
DragonWize schrieb:
I don't see it as any different as the big red neon hack me sign on the file that contains your database username and password.
We still do that as a convenience and then warn the user to set the permissions back. And it is not like more work, the user is already setting permissions to write then back it would just be one more done the same way, unless you do it all manually which is always an option.
This could all be solved by moving the default files directory into the sites directory.
I'd support this as a solution for new installations, definitely. Then there's only one chmod to do, and we can include the directory by default. And yeah, people who do multisite installations are going to have to do some more work, but they have to that anyway with settings.php. No big deal. -Angie
On 09 Dec 2007, at 1:32 AM, Angie Byron wrote:
And yeah, people who do multisite installations are going to have to do some more work, but they have to that anyway with settings.php. No big deal.
maybe ship with a __skeleton directory or something, that can be copied by the install process.
If they are running multisite it would be safe to assume they can do some tinkering with directories, we just have to document properly. Angie Byron wrote:
Gerhard Killesreiter wrote:
DragonWize schrieb:
I don't see it as any different as the big red neon hack me sign on the file that contains your database username and password.
We still do that as a convenience and then warn the user to set the permissions back. And it is not like more work, the user is already setting permissions to write then back it would just be one more done the same way, unless you do it all manually which is always an option.
This could all be solved by moving the default files directory into the sites directory.
I'd support this as a solution for new installations, definitely. Then there's only one chmod to do, and we can include the directory by default.
And yeah, people who do multisite installations are going to have to do some more work, but they have to that anyway with settings.php. No big deal.
-Angie
Emphasis on the "properly". :-) I had been going with the conventional wisdom of sites/<site>/files, but when I went to merge two sites into a multi-site to deploy them realized that wouldn't work; the path that is stored into the files table is then bound to the domain the site is on, which is no good because the domain changes from staging to production. So if we document sites/default/files for single-site installs, we need to in the same breath document to *not* use the sites/ directory for multi-site installs unless you want to make moving to a new server to be a PITA. On Saturday 08 December 2007, Shakur wrote:
If they are running multisite it would be safe to assume they can do some tinkering with directories, we just have to document properly.
Angie Byron wrote:
Gerhard Killesreiter wrote:
DragonWize schrieb:
I don't see it as any different as the big red neon hack me sign on the file that contains your database username and password.
We still do that as a convenience and then warn the user to set the permissions back. And it is not like more work, the user is already setting permissions to write then back it would just be one more done the same way, unless you do it all manually which is always an option.
This could all be solved by moving the default files directory into the sites directory.
I'd support this as a solution for new installations, definitely. Then there's only one chmod to do, and we can include the directory by default.
And yeah, people who do multisite installations are going to have to do some more work, but they have to that anyway with settings.php. No big deal.
-Angie
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote:
Emphasis on the "properly". :-) I had been going with the conventional wisdom of sites/<site>/files, but when I went to merge two sites into a multi-site to deploy them realized that wouldn't work; the path that is stored into the files table is then bound to the domain the site is on, which is no good because the domain changes from staging to production. So if we document sites/default/files for single-site installs, we need to in the same breath document to *not* use the sites/ directory for multi-site installs unless you want to make moving to a new server to be a PITA.
Perhaps the path in the files table should be relative to where the files directory is. You get the same issue when renaming sites
On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote:
Emphasis on the "properly". :-) I had been going with the conventional wisdom
of sites/<site>/files, but when I went to merge two sites into a multi-site
to deploy them realized that wouldn't work; the path that is stored into the
files table is then bound to the domain the site is on, which is no good
because the domain changes from staging to production. So if we document
sites/default/files for single-site installs, we need to in the same breath
document to *not* use the sites/ directory for multi-site installs unless you
want to make moving to a new server to be a PITA.
Perhaps a decoupling of the paths from the domain is in order. There is a way to do it today with symlinks: under "sites/" we have s1, s2, s3, ...etc. One directory per site. Then files would be "sites/s1/files". A symbolic link then makes s1 be site1.example.com, and s2 www.example.com and s3 is example3.com, ...etc. If you then decide to use .net instead of .com for s1, the file paths do not change at all. They remain the same. What this does is have one level of indirection, so we don't run into these hard coded domains in file path names. Maybe we should formalize that as the advocated solution. This works for all UNIX like systems. Not sure about those hosting/developing on Windows though.
Khalid Baheyeldin wrote:
On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote:
Emphasis on the "properly". :-) I had been going with the conventional wisdom of sites/<site>/files, but when I went to merge two sites into a multi-site to deploy them realized that wouldn't work; the path that is stored into the files table is then bound to the domain the site is on, which is no good because the domain changes from staging to production. So if we document sites/default/files for single-site installs, we need to in the same breath document to *not* use the sites/ directory for multi-site installs unless you want to make moving to a new server to be a PITA.
Perhaps a decoupling of the paths from the domain is in order.
There is a way to do it today with symlinks: under "sites/" we have s1, s2, s3, ...etc. One directory per site. Then files would be "sites/s1/files". A symbolic link then makes s1 be site1.example.com <http://site1.example.com>, and s2 www.example.com <http://www.example.com> and s3 is example3.com <http://example3.com>, ...etc.
My sites/ folder on my multisite installs is cluttered enough, thanks. Also, if I want to make changes to a site, I would have to first figure out what directory the symlink points to -- an unnecessary step that would definitely slow down my workflow. <snip>
Maybe we should formalize that as the advocated solution. This works for all UNIX like systems. Not sure about those hosting/developing on Windows though.
Actually, it doesn't. It works for all of us pros on our own servers just fine, but for Joe Hobbyist who is running a multisite install on cheap shared hosting (where he has FTP access, but not SSH), this approach is impossible. Without any actual statistics available, I'm willing to guess that this is common enough not to be dismissed as an edge case. Susan
On Dec 9, 2007 11:33 AM, Susan Stewart <HedgeMage@binaryredneck.net> wrote:
Khalid Baheyeldin wrote:
On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote:
Emphasis on the "properly". :-) I had been going with the conventional wisdom of sites/<site>/files, but when I went to merge two sites into a multi-site to deploy them realized that wouldn't work; the path that is stored into the files table is then bound to the domain the site is on, which is no good because the domain changes from staging to production. So if we document sites/default/files for single-site installs, we need to in the same breath document to *not* use the sites/ directory for multi-site installs unless you want to make moving to a new server to be a PITA.
Perhaps a decoupling of the paths from the domain is in order.
There is a way to do it today with symlinks: under "sites/" we have s1, s2, s3, ...etc. One directory per site. Then files would be "sites/s1/files". A symbolic link then makes s1 be site1.example.com <http://site1.example.com>, and s2 www.example.com <http://www.example.com> and s3 is example3.com <http://example3.com>, ...etc.
My sites/ folder on my multisite installs is cluttered enough, thanks. Also, if I want to make changes to a site, I would have to first figure out what directory the symlink points to -- an unnecessary step that would definitely slow down my workflow.
Symlinks is just what works today, and acceptable for installations with not too many sites. Granted, you get the bramble bush that comes with it and that can be unwieldy. Perhaps the indirection should be formalized in a different way, with a map of some sort (domain -> directory), either in a master file under sites, or in the database (slow). map.conf <?php $map = array( // Site domain/subdomain => site ID and 'example.com' => 'site1', 'example2.com' => 'site3', 'example7.com' => 'mydir5', 'site3.example.com' => 'otherdir2', ); Once a site gets an ID/Dir, this does not change at all for the lifetime of the site. Domains/Subdomains can be changed at will, such as when moving a site from test to live, or from multisite to standalone, ...etc. -- Khalid M. Baheyeldin 2bits.com http://2bits.com Drupal optimization, development, customization and consulting.
On Dec 9, 2007 12:15 PM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Dec 9, 2007 11:33 AM, Susan Stewart <HedgeMage@binaryredneck.net> wrote:
Khalid Baheyeldin wrote:
On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote:
Emphasis on the "properly". :-) I had been going with the conventional wisdom of sites/<site>/files, but when I went to merge two sites into a multi-site to deploy them realized that wouldn't work; the path that is stored into the files table is then bound to the domain the site is on, which is no good because the domain changes from staging to production. So if we document sites/default/files for single-site installs, we need to in the same breath document to *not* use the sites/ directory for multi-site installs unless you want to make moving to a new server to be a PITA.
Perhaps a decoupling of the paths from the domain is in order.
There is a way to do it today with symlinks: under "sites/" we have s1, s2, s3, ...etc. One directory per site. Then files would be "sites/s1/files". A symbolic link then makes s1 be site1.example.com <http://site1.example.com >, and s2 www.example.com <http://www.example.com> and s3 is example3.com <http://example3.com>, ...etc.
My sites/ folder on my multisite installs is cluttered enough, thanks. Also, if I want to make changes to a site, I would have to first figure out what directory the symlink points to -- an unnecessary step that would definitely slow down my workflow.
Symlinks is just what works today, and acceptable for installations with not too many sites. Granted, you get the bramble bush that comes with it and that can be unwieldy.
Perhaps the indirection should be formalized in a different way, with a map of some sort (domain -> directory), either in a master file under sites, or in the database (slow).
map.conf <?php
$map = array( // Site domain/subdomain => site ID and 'example.com' => 'site1', ' example2.com' => 'site3', 'example7.com' => 'mydir5', 'site3.example.com' => 'otherdir2', );
Once a site gets an ID/Dir, this does not change at all for the lifetime of the site. Domains/Subdomains can be changed at will, such as when moving a site from test to live, or from multisite to standalone, ...etc.
The above indirection scheme will solve another thing: 404s for externally visible paths. Using a unique site id for a directory will prevent external 404s from happening if you move the site to another domain.
The /sites/* solution makes sense for many multisite configs, I feel ... Just as long as there's an admin-configurable way to override the default. E.g., for private files configurations I've always preferred going above the webroot, such as "../sampledirectory Would hate to have to go through sysadmin-level coding contortions to override a newly rigid default. Or am I misunderstanding the thread? Laura On Dec 9, 2007, at 6:31 PM, Khalid Baheyeldin wrote:
On Dec 9, 2007 12:15 PM, Khalid Baheyeldin <kb@2bits.com> wrote: On Dec 9, 2007 11:33 AM, Susan Stewart <HedgeMage@binaryredneck.net> wrote: Khalid Baheyeldin wrote:
On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote:
Emphasis on the "properly". :-) I had been going with the conventional wisdom of sites/<site>/files, but when I went to merge two sites into a multi-site to deploy them realized that wouldn't work; the path that is stored into the files table is then bound to the domain the site is on, which is no good because the domain changes from staging to production. So if we document sites/default/files for single-site installs, we need to in the same breath document to *not* use the sites/ directory for multi-site installs unless you want to make moving to a new server to be a PITA.
Perhaps a decoupling of the paths from the domain is in order.
There is a way to do it today with symlinks: under "sites/" we have s1, s2, s3, ...etc. One directory per site. Then files would be "sites/s1/files". A symbolic link then makes s1 be site1.example.com <http://site1.example.com >, and s2 www.example.com <http://www.example.com> and s3 is example3.com <http://example3.com>, ...etc.
My sites/ folder on my multisite installs is cluttered enough, thanks. Also, if I want to make changes to a site, I would have to first figure out what directory the symlink points to -- an unnecessary step that would definitely slow down my workflow.
Symlinks is just what works today, and acceptable for installations with not too many sites. Granted, you get the bramble bush that comes with it and that can be unwieldy.
Perhaps the indirection should be formalized in a different way, with a map of some sort (domain -> directory), either in a master file under sites, or in the database (slow).
map.conf <?php
$map = array( // Site domain/subdomain => site ID and 'example.com' => 'site1', ' example2.com' => 'site3', 'example7.com' => 'mydir5', 'site3.example.com' => 'otherdir2', );
Once a site gets an ID/Dir, this does not change at all for the lifetime of the site. Domains/Subdomains can be changed at will, such as when moving a site from test to live, or from multisite to standalone, ...etc.
The above indirection scheme will solve another thing: 404s for externally visible paths. Using a unique site id for a directory will prevent external 404s from happening if you move the site to another domain.
On 10 Dec 2007, at 5:10 AM, Laura Scott wrote:
The /sites/* solution makes sense for many multisite configs, I feel ... Just as long as there's an admin-configurable way to override the default. E.g., for private files configurations I've always preferred going above the webroot, such as "../sampledirectory you'd just set it to ../sampledirectory
Only the default would change .
On 10 Dec 2007, at 2:31 AM, Khalid Baheyeldin wrote:
The above indirection scheme will solve another thing: 404s for externally visible paths. Using a unique site id for a directory will prevent external 404s from happening if you move the site to another domain.
i have a patch that allows you to specify the site directory in the apache vhost file, which i made for the same purpose.
Khalid Baheyeldin wrote:
On Dec 9, 2007 12:15 PM, Khalid Baheyeldin <kb@2bits.com <mailto:kb@2bits.com>> wrote:
On Dec 9, 2007 11:33 AM, Susan Stewart <HedgeMage@binaryredneck.net <mailto:HedgeMage@binaryredneck.net>> wrote:
Khalid Baheyeldin wrote: > > > On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote: > >> Emphasis on the "properly". :-) I had been going with the >> conventional wisdom of sites/<site>/files, but when I went to merge >> two sites into a multi-site to deploy them realized that wouldn't >> work; the path that is stored into the files table is then bound to >> the domain the site is on, which is no good because the domain >> changes from staging to production. So if we document >> sites/default/files for single-site installs, we need to in the >> same breath document to *not* use the sites/ directory for >> multi-site installs unless you want to make moving to a new server >> to be a PITA. > > Perhaps a decoupling of the paths from the domain is in order. > > There is a way to do it today with symlinks: under "sites/" we have > s1, s2, s3, ...etc. One directory per site. Then files would be > "sites/s1/files". A symbolic link then makes s1 be site1.example.com <http://site1.example.com> > <http://site1.example.com <http://site1.example.com>>, and s2 www.example.com <http://www.example.com> > <http://www.example.com> and s3 is example3.com <http://example3.com> > <http://example3.com>, ...etc.
My sites/ folder on my multisite installs is cluttered enough, thanks. Also, if I want to make changes to a site, I would have to first figure out what directory the symlink points to -- an unnecessary step that would definitely slow down my workflow.
Symlinks is just what works today, and acceptable for installations with not too many sites. Granted, you get the bramble bush that comes with it and that can be unwieldy.
Perhaps the indirection should be formalized in a different way, with a map of some sort (domain -> directory), either in a master file under sites, or in the database (slow).
map.conf <?php
$map = array( // Site domain/subdomain => site ID and 'example.com <http://example.com>' => 'site1', ' example2.com <http://example2.com>' => 'site3', 'example7.com <http://example7.com>' => 'mydir5', 'site3.example.com <http://site3.example.com>' => 'otherdir2', );
Once a site gets an ID/Dir, this does not change at all for the lifetime of the site. Domains/Subdomains can be changed at will, such as when moving a site from test to live, or from multisite to standalone, ...etc.
The above indirection scheme will solve another thing: 404s for externally visible paths. Using a unique site id for a directory will prevent external 404s from happening if you move the site to another domain.
Just what I was thinking: http://drupal.org/node/98824#comment-648260 No symlink clutter, no need for CLI access. Now, would it be possible to somehow manage this file through Drupal (perhaps just as install.php does with settings.php)? Gaele
Windows has an equivalent symlinks functionality, but its not present in S.O. by default. You need to download a small .exe to do the trick. Feijó ----- Original Message ----- From: Khalid Baheyeldin To: development@drupal.org Sent: Sunday, December 09, 2007 1:33 PM Subject: Re: [development] Files directory on installation usability fix notquite usable. ; ) Perhaps a decoupling of the paths from the domain is in order. There is a way to do it today with symlinks: under "sites/" we have s1, s2, s3, ...etc. One directory per site. Then files would be "sites/s1/files". A symbolic link then makes s1 be site1.example.com, and s2 www.example.com and s3 is example3.com, ...etc. If you then decide to use .net instead of .com for s1, the file paths do not change at all. They remain the same. What this does is have one level of indirection, so we don't run into these hard coded domains in file path names. Maybe we should formalize that as the advocated solution. This works for all UNIX like systems. Not sure about those hosting/developing on Windows though.
Quoting Alessandro Feijó <patrao@legendas.feijo.info>:
Windows has an equivalent symlinks functionality, but its not present in S.O. by default.
At the directory level only.
You need to download a small .exe to do the trick.
Junction.exe The syntax is backwards. There is no means to easily know that it is a junction. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie Boyd wrote:
Quoting Alessandro Feijó <patrao@legendas.feijo.info>:
Windows has an equivalent symlinks functionality, but its not present in S.O. by default.
At the directory level only.
You need to download a small .exe to do the trick.
Junction.exe The syntax is backwards. There is no means to easily know that it is a junction.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Windows 6.x (Vista) has 'kinda sorta' symlinks - both hard and soft - easy enough to create at the command line. And they can even span drives (c: > e:) Only problem is that they are not unix symlinks - and a checkout from an svn repo (for example) that contains checked in symlinks will not be understood by windows. andre
----- Original Message ----- From: "adrian rossouw" <adrian@bryght.com> To: <development@drupal.org> Sent: Sunday, December 09, 2007 8:37 AM Subject: Re: [development] Files directory on installation usability fix notquite usable. ; )
Perhaps the path in the files table should be relative to where the files directory is.
I've been wondering about this myself since I got bit by it in 4.7. I never understood why the whole path is stuck in there. Makes it a real PITA to move the files directory. Michelle
On Dec 9, 2007 10:54 AM, Michelle Cox <mcox@charter.net> wrote:
----- Original Message ----- From: "adrian rossouw" <adrian@bryght.com> To: <development@drupal.org> Sent: Sunday, December 09, 2007 8:37 AM Subject: Re: [development] Files directory on installation usability fix notquite usable. ; )
Perhaps the path in the files table should be relative to where the files directory is.
I've been wondering about this myself since I got bit by it in 4.7. I never understood why the whole path is stuck in there. Makes it a real PITA to move the files directory.
Michelle
Good point. This needs to be solved. But, it will not address any themes or modules that are under site specific directories (e.g. sites/example.com/modules, sites/example.com/themes). For those, the domain name is still in the path of all images, css, and js files. -- Khalid M. Baheyeldin 2bits.com http://2bits.com Drupal optimization, development, customization and consulting.
Ah, this is interesting. Correct me if I am wrong, but css background images, for example, are relative according to best practices; likewise, in a module, things like the following are best practices (if you are forced to invoke from theme): <script type="text/javascript" src="<?php echo base_path() . 'misc/collapse.js'?>"></script> likewise path_to_theme(), drupal_get_path() define("JS_directory", drupal_get_path('module', 'this_wonderful_module') . '/js/'); Anyway, on a joyous note, today Tao Starbow announces yet another module, scanner, which offers search and replace in configurable content types and tables... maybe not everything being sought here, but a big help to some of the PITA procedures being mentioned. See his Global Search and Replace article http://www.starbowconsulting.com/node/88 Victor Kane http://awebfactory.com.ar On Dec 9, 2007 1:24 PM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Dec 9, 2007 10:54 AM, Michelle Cox <mcox@charter.net> wrote:
----- Original Message ----- From: "adrian rossouw" <adrian@bryght.com> To: <development@drupal.org > Sent: Sunday, December 09, 2007 8:37 AM Subject: Re: [development] Files directory on installation usability fix notquite usable. ; )
Perhaps the path in the files table should be relative to where the files directory is.
I've been wondering about this myself since I got bit by it in 4.7. I never understood why the whole path is stuck in there. Makes it a real PITA to move the files directory.
Michelle
Good point. This needs to be solved.
But, it will not address any themes or modules that are under site specific directories (e.g. sites/example.com/modules, sites/example.com/themes). For those, the domain name is still in the path of all images, css, and js files. -- Khalid M. Baheyeldin 2bits.com http://2bits.com Drupal optimization, development, customization and consulting.
On 09 Dec 2007, at 6:24 PM, Khalid Baheyeldin wrote:
But, it will not address any themes or modules that are under site specific directories (e.g. sites/example.com/modules, sites/example.com/ themes). For those, the domain name is still in the path of all images, css, and js files.
make those relative too. to the path in the systems table. we use a variable / path to get it anyway.
Michelle Cox wrote:
From: "adrian rossouw" <adrian@bryght.com>
Perhaps the path in the files table should be relative to where the files directory is.
I've been wondering about this myself since I got bit by it in 4.7. I never understood why the whole path is stuck in there. Makes it a real PITA to move the files directory.
Michelle
Correct me if I'm wrong, but I think that putting the whole path in there allows sites using the public file transfer method to do plain http file transfers instead of having to load Drupal to handle every file request. While Adrian's suggestion would involve a noticeable performance hit for some sites, it might be nice to see as a contrib module. Sites using private file transfer are loading Drupal on each request anyway, so the performance question is moot there. Also, small, low traffic sites might just plain not care. Susan
Correct me if I'm wrong, but I think that putting the whole path in there allows sites using the public file transfer method to do plain http file transfers instead of having to load Drupal to handle every file request.
While Adrian's suggestion would involve a noticeable performance hit for some sites, it might be nice to see as a contrib module. Sites using private file transfer are loading Drupal on each request anyway, so the performance question is moot there. Also, small, low traffic sites might just plain not care.
Susan
No offense, but you are wrong here. Drupal is loaded on private file because those files are either placed outside the root directory or disallowed access via another method. The reason drupal is loaded each time is to check authentication and then pass the non-publicly accessible file through the connection. Making the file path in the files table relative to the files folders would just require one change throughout drupal (core and contrib), you would have to do something like this when you link to a file: drupal_get_files_path() . $relative_file_path_in_db As that produces the direct link and the file is public accessible, drupal is not loaded. -- Alan Doucette Koi Technology, LLC www.KoiTech.net
DragonWize wrote: <snip>
Making the file path in the files table relative to the files folders would just require one change throughout drupal (core and contrib), you would have to do something like this when you link to a file:
drupal_get_files_path() . $relative_file_path_in_db
As that produces the direct link and the file is public accessible, drupal is not loaded.
I think we're talking about two different things (sort of) -- you are saying that the path in the files table would be relative to the files dir, but the normal real path would still be presented to the user's client, so normal http could still be used. For some reason I'd just assumed that files would also be aliased to http://www.example.com/files/filename so that if the directory were moved, it would be totally transparent to the user. I'd pictured Drupal loading to handle the alias. Thanks for setting me straight, Susan
On 09 Dec 2007, at 7:01 PM, Susan Stewart wrote:
While Adrian's suggestion would involve a noticeable performance hit for some sites, it might be nice to see as a contrib module. Sites using private file transfer are loading Drupal on each request anyway, so the performance question is moot there. Also, small, low traffic sites might just plain not care.
umm. no. we generate the links based on the place where it is, we just change how we store the information.
I have summarized my proposal and view here: http://drupal.org/node/98824#comment-653837 -- Alan Doucette Koi Technology, LLC www.KoiTech.net
adrian rossouw wrote:
On 09 Dec 2007, at 7:01 PM, Susan Stewart wrote:
While Adrian's suggestion would involve a noticeable performance hit for some sites, it might be nice to see as a contrib module. Sites using private file transfer are loading Drupal on each request anyway, so the performance question is moot there. Also, small, low traffic sites might just plain not care.
umm. no.
we generate the links based on the place where it is, we just change how we store the information.
Yeah, DragonWize already corrected me :) Susan
The whole path is used because the files directory is not necessarily a subdirectory of drupal. There are good reasons, both for security and convenience of storage, why one would store private files outsite of any directory served by the web server. Say my drupal is installed in /var/www/drupal; my files might be in /var/private_files/... Many of us have bumped into the various limitations of drupal's file handling, and many modules have attempted to improve the situation. I just want to say that in solving the usability problem discussed on this thread, let's not lose the ability to have private files (or even public) stored outside of where Drupal is installed. -Dave On Sun, 9 Dec 2007 09:54:23 -0600, "Michelle Cox" <mcox@charter.net> said:
I've been wondering about this myself since I got bit by it in 4.7. I never understood why the whole path is stuck in there. Makes it a real PITA to move the files directory.
On Dec 8, 2007 8:30 PM, Larry Garfield <larry@garfieldtech.com> wrote:
Emphasis on the "properly". :-) I had been going with the conventional wisdom of sites/<site>/files, but when I went to merge two sites into a multi-site to deploy them realized that wouldn't work; the path that is stored into the files table is then bound to the domain the site is on, which is no good because the domain changes from staging to production. So if we document sites/default/files for single-site installs, we need to in the same breath document to *not* use the sites/ directory for multi-site installs unless you want to make moving to a new server to be a PITA.
I just want to point everyone towards: http://drupal.org/node/98824 "Use of sites/*/files as the default files directory" A lot of what's been mentioned in this thread has already been discussed over there. It might be better to continue the discussion there. andrew
participants (20)
-
adrian rossouw -
Alessandro Feijó -
Andre Molnar -
andrew morton -
Angela Byron -
Angie Byron
-
David Cohen -
DragonWize -
Earnie Boyd -
Gaele Strootman -
Gerhard Killesreiter -
Khalid Baheyeldin -
Larry Garfield -
Laura Scott -
Michelle Cox -
Robert Douglass -
Shakur -
Susan Stewart -
Victor Kane -
Wim Mostrey