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 <[email protected]>wrote: > On Wed, Jul 15, 2009 at 5:54 PM, Bevan Rudge <[email protected]>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
