[development] Files table includes file_directory_path

[larry at garfieldtech.com]

sites.php was actually added specifically for this sort of issue, 
because the sites/ directory structure was too brittle.

Of course, for the files directories in particular I have long since 
dropped using sites/<sitename>/files in favor of files/<sitekey>, which 
sidesteps the issue entirely.  That doesn't need to change no matter 
what server the site moves to.

Khalid Baheyeldin wrote:
> As others said, you either use symlinks (which forces you to have two 
> directories per site), or the new sites.php feature of Drupal 7.
> 
> Using that, you can have a contrived name for each site (even site1, 
> site2, or an md5 hash for each site), and redirect the site in it.
> 
> The trick is to not use sites/default for each site from now on, and 
> only use a unique identifier. That identifier can be the same when you 
> develop the site, and remains the same when you deploy the site.
> 
> On Thu, Jul 16, 2009 at 9:50 AM, Ashraf Amayreh <mistknight at gmail.com 
> <mailto:mistknight at gmail.com>> wrote:
> 
>     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 <mailto:kathleen at ceardach.com>> wrote:
> 
>         On Wed, Jul 15, 2009 at 5:54 PM, Bevan Rudge
>         <bevan at civicactions.com <mailto: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
> 
> 
> 
> 
> -- 
> Khalid M. Baheyeldin
> 2bits.com <http://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