Date: Wed, 15 Jul 2009 17:09:21 +0200 From: Clemens Tolboom <clemens@build2be.nl> Subject: [development] 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?
There is a featurebug in Drupal core that has been around since Drupal 5 or before, where the file API allows modules to save and retrieve files using a path relative to either the Drupal root or variable_get('file_directory_path', ...). A number of people have tried to fix this (including myself) in Drupal core, but it is a rather overwhelming issue since so much code in core and contrib now expects not only the file API, but also the files table to include variable_get('file_directory_path', ...). Attempts to fix it in the past sometimes gets distracted by related issues such as sites/sites.php and default files_directory_path, which don't actually solve the featurebug. At CivicActions we have a tool (pushdb --xFix) that fixes the paths in the files directory and elsewhere in the db, which we run when copying an instance of the site to a staging environment. However this approach is becoming unsustainable and we are considering using a separate instances of Drupal core in each and every staging environment so that they all use sites/default. What this means is that much of the time this featurebug is such a PITA that Drupal's multisite features don't work for staging environments. In my own sandbox I don't use multisite for staging environments at all, because of this issue, Do others?
Message: 6 Date: Wed, 15 Jul 2009 19:02:38 +0300 From: ufuk bayburt <ufukbay@gmail.com> Subject: Re: [development] Why is the Drupal File System relative to website root and not relative to admin/settings/file-system path?
That's the cleanest fix for this bug I've seen yet, but still seems to have wider ramifications than that patch fixes, and that's just Drupal core. I think it also needs an update handler that fixes paths in the files table for Drupal 6 sites upgrading to Drupal 7.
Date: Wed, 15 Jul 2009 11:08:44 -0500 From: James Gilliland <neclimdul@gmail.com> Subject: Re: [development] Why is the Drupal File System relative to website root and not relative to admin/settings/file-system path?
Set up your production filesystem path first and set that before developing your site?
You misunderstood the initial post. The poster is asking about the case where he/she creates a staging environment from the live environment, not the other way around. However you've raised another issue derived from this featurebug. If you are developing a site on a domain which will not be the final domain name (e.g. because the site you're developing is replacing a non-drupal site), and your conf_path() is not sites/default, then you need to set your files_directory_path beforehand and/or create a system of symlinks to workaround the featurebug (or be screwed if your on windows). The foresight usually come with the experience of having been burned by this featurebug – probably when you deployed a site and all the files broke a previous time. This hurts the developer experience.
Date: Wed, 15 Jul 2009 12:39:17 -0400 From: Moshe Weitzman <weitzman@tejasa.com> Subject: Re: [development] Why is the Drupal File System relative to website root and not relative to admin/settings/file-system path?
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.
While that's a great feature it doesn't fix this featurebug, it just provides another workaround for when it breaks and for those with foresight. Bevan/