[development] Files table includes file_directory_path

[Ashraf Amayreh]

Storing a file's path which may change in the future inside the database is
a bug no matter what the use case is.

I had once developed a site and then decided to move the files from
sites/default/ to sites/<domain-name>/ in order to create a new site using
the same installation and was very surprised at seeing this bug. The path is
stored in the files and users table (for profile pics) I believe.

On Thu, Jul 16, 2009 at 1:15 AM, Kathleen Murtagh <kathleen at ceardach.com>wrote:

> On Wed, Jul 15, 2009 at 5:54 PM, Bevan Rudge <bevan at civicactions.com>wrote:
>
>> 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?
>>
>
> I don't use multisite for managing dev, staging and production
> environments.  In my workflow, it would be *more* complicated to use this
> method.  I put the entirety of Drupal core into version control and deploy
> working spaces straight from version control.  This makes it much easier to
> control exactly what and when code is pushed to production, and enable the
> ability navigate through the history to find sources of bugs.
>
> The only time I use multisite is for actual separate, yet integrated
> websites.  The most common use for me are multiple websites that share
> tables, like the user-related tables.
>



-- 
Ashraf Amayreh
http://aamayreh.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090716/f2cd9cf6/attachment.htm>