Why is the Drupal File System relative to website root and not relative to admin/settings/file-system path?
Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment. One has to update the files database table and more tables or do trickery with symlinks to get the site running clean. If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path. What do you think? Did I miss something important?
On Wed, Jul 15, 2009 at 6:09 PM, Clemens Tolboom <clemens@build2be.nl>wrote:
Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment.
One has to update the files database table and more tables or do trickery with symlinks to get the site running clean.
If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path.
What do you think? Did I miss something important?
Set up your production filesystem path first and set that before developing your site? On Wed, Jul 15, 2009 at 11:02 AM, ufuk bayburt<ufukbay@gmail.com> wrote:
On Wed, Jul 15, 2009 at 6:09 PM, Clemens Tolboom <clemens@build2be.nl> wrote:
Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment.
One has to update the files database table and more tables or do trickery with symlinks to get the site running clean.
If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path.
What do you think? Did I miss something important?
Thanks for the link
Fiddling with http://api.drupal.org/api/function/conf_path/7 is off course a solution but it misses the 'it works out of the box' wish. But maybe I'm just too lazy ;) I now use sites/default/files more and skip the multi site option for making staging more workable. Production is not always under control ie when having a NFS mounted files directory improper sym linked.
Quoting Clemens Tolboom <clemens@build2be.nl>:
Production is not always under control ie when having a NFS mounted files directory improper sym linked.
True for larger companies but the symlinks discussed were directories within the sites/ directory. There should be no issue of improper symlink because the directories for the symlink live in the same directory as the symlink. E.G.: cd sites/ mkdir sample.com ln -s sample.com www.sample.com ln -s sample.com dev.sample.com I do this for sites that can be accessed by www.sample.com as well as sample.com. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
fixed in d7 with sites/sites.php. you can map one path to another so the that two environments can be made to look the same. see http://api.drupal.org/api/function/conf_path/7. of course d6 still needs some tricks. On Wed, Jul 15, 2009 at 11:09 AM, Clemens Tolboom<clemens@build2be.nl> wrote:
Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment.
One has to update the files database table and more tables or do trickery with symlinks to get the site running clean.
If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path.
What do you think? Did I miss something important?
Clemens Tolboom wrote:
Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment.
One has to update the files database table and more tables or do trickery with symlinks to get the site running clean.
If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path.
What do you think? Did I miss something important?
On *nix you can easily workaround this problem by creating your site directory as sites/sitename and adding the actual urls as symlinks So you get something as directory: mysite link: www.mysite.com -> mysite link: dev.mysite.com -> mysite entries in the files table will always look like sites/mysite/files/file.ext and are the same for dev and prod... Luc
Quoting Luc Stroobant <lstroobant@gmail.com>:
Clemens Tolboom wrote:
Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment.
One has to update the files database table and more tables or do trickery with symlinks to get the site running clean.
If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path.
What do you think? Did I miss something important?
On *nix you can easily workaround this problem by creating your site directory as sites/sitename and adding the actual urls as symlinks
So you get something as
directory: mysite link: www.mysite.com -> mysite link: dev.mysite.com -> mysite
entries in the files table will always look like sites/mysite/files/file.ext and are the same for dev and prod...
And on windows junction www.mysite.com mysite junction dev.mysite.com mysite -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
I don't really understand why the files are not just stored relative to the files folder rather than the site root. That way, changing the location of the files folder would only entail changing the file path inside the administration. When retrieving file paths the function doing that could simply call file_directory_path() and append the filepath from the database. Isn't this how it should standardly be dealt with, or did I miss something? AA On Thu, Jul 16, 2009 at 4:40 PM, Earnie Boyd <earnie@users.sourceforge.net>wrote:
Quoting Luc Stroobant <lstroobant@gmail.com>:
Clemens Tolboom wrote:
Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment.
One has to update the files database table and more tables or do trickery with symlinks to get the site running clean.
If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path.
What do you think? Did I miss something important?
On *nix you can easily workaround this problem by creating your site directory as sites/sitename and adding the actual urls as symlinks
So you get something as
directory: mysite link: www.mysite.com -> mysite link: dev.mysite.com -> mysite
entries in the files table will always look like sites/mysite/files/file.ext and are the same for dev and prod...
And on windows
junction www.mysite.com mysite junction dev.mysite.com mysite
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
-- Ashraf Amayreh http://aamayreh.org
Even if you solve the issue with drupal generated paths (e.g. the ones stored in the files table), you still have a lot of stuff that is in HTML and needs to change (e.g. <img src=...> tags, ...etc. which are not easily changed. So having a good value from the start is important. On Thu, Jul 16, 2009 at 9:57 AM, Ashraf Amayreh <mistknight@gmail.com>wrote:
I don't really understand why the files are not just stored relative to the files folder rather than the site root.
That way, changing the location of the files folder would only entail changing the file path inside the administration.
When retrieving file paths the function doing that could simply call file_directory_path() and append the filepath from the database. Isn't this how it should standardly be dealt with, or did I miss something?
AA
On Thu, Jul 16, 2009 at 4:40 PM, Earnie Boyd <earnie@users.sourceforge.net
wrote:
Quoting Luc Stroobant <lstroobant@gmail.com>:
Clemens Tolboom wrote:
Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment.
One has to update the files database table and more tables or do trickery with symlinks to get the site running clean.
If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path.
What do you think? Did I miss something important?
On *nix you can easily workaround this problem by creating your site directory as sites/sitename and adding the actual urls as symlinks
So you get something as
directory: mysite link: www.mysite.com -> mysite link: dev.mysite.com -> mysite
entries in the files table will always look like sites/mysite/files/file.ext and are the same for dev and prod...
And on windows
junction www.mysite.com mysite junction dev.mysite.com mysite
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
-- Ashraf Amayreh http://aamayreh.org
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
There's also benefits to it being absolute. If my /files folder is becoming bloated and I decide I want to start a fresh files directory all I have to do is change the file path inside admin. All my old file paths will still be intact. Making it relative would then break the archived /files path. If moving the file system were actually that common of an occurrence then I could see this being a big problem. But to do things like moving from a development/staging area to a production area a simple query does the trick: UPDATE files SET filepath=REPLACE(filepath, '/sites/www.oldserver.com/file', '/sites/www.newserver.com/file'); User pictures: UPDATE users SET picture=REPLACE(picture, '/sites/www.oldserver.com/file', '/sites/www.newserver.com/file'); This has never been a problem for me when it comes to having to move a file system. Jamie Holly http://www.intoxination.net http://www.hollyit.net Ashraf Amayreh wrote:
I don't really understand why the files are not just stored relative to the files folder rather than the site root.
That way, changing the location of the files folder would only entail changing the file path inside the administration.
When retrieving file paths the function doing that could simply call file_directory_path() and append the filepath from the database. Isn't this how it should standardly be dealt with, or did I miss something?
AA
On Thu, Jul 16, 2009 at 4:40 PM, Earnie Boyd <earnie@users.sourceforge.net <mailto:earnie@users.sourceforge.net>> wrote:
Quoting Luc Stroobant <lstroobant@gmail.com <mailto:lstroobant@gmail.com>>:
Clemens Tolboom wrote:
Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment.
One has to update the files database table and more tables or do trickery with symlinks to get the site running clean.
If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path.
What do you think? Did I miss something important?
On *nix you can easily workaround this problem by creating your site directory as sites/sitename and adding the actual urls as symlinks
So you get something as
directory: mysite link: www.mysite.com <http://www.mysite.com> -> mysite link: dev.mysite.com <http://dev.mysite.com> -> mysite
entries in the files table will always look like sites/mysite/files/file.ext and are the same for dev and prod...
And on windows
junction www.mysite.com <http://www.mysite.com> mysite junction dev.mysite.com <http://dev.mysite.com> mysite
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
-- Ashraf Amayreh http://aamayreh.org
On Thu, Jul 16, 2009 at 9:57 AM, Ashraf Amayreh<mistknight@gmail.com> wrote:
I don't really understand why the files are not just stored relative to the files folder rather than the site root.
That way, changing the location of the files folder would only entail changing the file path inside the administration.
When retrieving file paths the function doing that could simply call file_directory_path() and append the filepath from the database. Isn't this how it should standardly be dealt with, or did I miss something?
Not to pick on you specifically, but if you'd read through the issue that ufuk linked to in the very first reply to this thread (http://drupal.org/node/366464) you'll find plenty of discussion about the complications that prevent this from being such a "simple" change. Can we please move this discussion over to the issue queue? andrew
participants (10)
-
andrew morton -
Ashraf Amayreh -
Clemens Tolboom -
Earnie Boyd -
James Gilliland -
Jamie Holly -
Khalid Baheyeldin -
Luc Stroobant -
Moshe Weitzman -
ufuk bayburt