[development] Files table includes file_directory_path

Ashraf Amayreh mistknight at gmail.com
Thu Jul 16 13:50:20 UTC 2009

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090716/f2cd9cf6/attachment.htm>

More information about the development mailing list