Да, это возможно - я запускаю сайт drupal на http://www.blah.net, и сайт разработки / тестирования на http://dev.blah.net. Они оба используют один и тот же код, извлеченный из общего хранилища svn, и они оба используют одну и ту же базу данных.
Это прекрасно работает для меня, исходя из следующих условий:
Строка вашего settings.php, которая определяет $ base_url, должна быть закомментирована.
Строка, определяющая $ cookie_domain, должна быть заменена условным именем на сервере, чтобы избежать сумасшедших входов в систему .:
if(preg_match('/dev/i', $_SERVER['SERVER_NAME'])) {
$cookie_domain = 'dev.blah.net';
} else {
$cookie_domain = 'www.blah.net';
}
Хотя это все нормально для меня, это потому, что мои пути отображаются точно так же (оба приложения drupal расположены в корне домена). Первоначально у меня был www.blah.net/dev, но он сломался, потому что пути больше не работают.
Так, решение - убедиться, что карта путей. Возможно, у вас есть достаточный доступ для реализации Apache VirtualHost на сайте, на котором вы хотите протестировать? Если это так, то вы можете добавить запись виртуального хоста, как это:
<VirtualHost dev.blah.net:80>
ServerName dev.blah.net
ServerAlias blah.net
DirectoryIndex index.php
#change this to the path to the drupal install
DocumentRoot /www/htdocs/
<Directory "/www/htdocs">
## Allow CGI and Symbolic Links
Options +FollowSymLinks +ExecCGI
# NOTE - The FileInfo override allows rewrites to work in htaccess files
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Еще одно замечание: несмотря на то, что вы можете без каких-либо проблем поддерживать отдельные шаблоны и физические файлы, если вы измените конфигурацию через панель администратора, эти параметры будут сохранены в базе данных и будут действовать на все установки, использующие базу данных. Блоки являются типичным примером этой проблемы, поскольку они хранятся в базе данных.
В принципе, у вас не может быть двух разных наборов сопоставлений путей для drupal (предоставлено, вы могли бы сделать несколько безумных переписываний apache, но это могло бы стать очень грязным). Ответ от Virtualhost, вероятно, является наименее болезненным решением, если у вас есть достаточный доступ.