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