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.<br><br>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.<br>
<br>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.<br><br><div class="gmail_quote">
On Thu, Jul 16, 2009 at 9:50 AM, Ashraf Amayreh <span dir="ltr"><<a href="mailto:mistknight@gmail.com">mistknight@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">Storing a file's path which may change in the future inside the database is a bug no matter what the use case is.<br><br>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.<div>
<div></div><div class="h5"><br>
<br><div class="gmail_quote">On Thu, Jul 16, 2009 at 1:15 AM, Kathleen Murtagh <span dir="ltr"><<a href="mailto:kathleen@ceardach.com" target="_blank">kathleen@ceardach.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="gmail_quote">On Wed, Jul 15, 2009 at 5:54 PM, Bevan Rudge <span dir="ltr"><<a href="mailto:bevan@civicactions.com" target="_blank">bevan@civicactions.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At CivicActions we have a tool (pushdb --xFix) that fixes the paths in<br>
the files directory and elsewhere in the db, which we run when copying<br>
an instance of the site to a staging environment. However this<br>
approach is becoming unsustainable and we are considering using a<br>
separate instances of Drupal core in each and every staging<br>
environment so that they all use sites/default.<br>
<br>
What this means is that much of the time this featurebug is such a<br>
PITA that Drupal's multisite features don't work for staging<br>
environments. In my own sandbox I don't use multisite for staging<br>
environments at all, because of this issue, Do others?<br>
</blockquote></div><br></div>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.<br>
<br>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.<br>
</blockquote></div><br><br clear="all"><br></div></div>-- <br>Ashraf Amayreh<br><a href="http://aamayreh.org" target="_blank">http://aamayreh.org</a><br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com">2bits.com</a>, Inc.<br><a href="http://2bits.com">http://2bits.com</a><br>Drupal optimization, development, customization and consulting.<br>
Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra<br>Simplicity is the ultimate sophistication. -- Leonardo da Vinci<br>