Предложения для settings.php - локальный разработчик, сервер разработки, живой сервер

80

По сути, это один из величайших вопросов всех времен: каким образом вы используете settings.php в своем процессе разработки / подготовки?

Прямо сейчас у меня есть файл settings.php, настроенный следующим образом, и я основываю свою разработку на директиве $ HOST сервера - это означает, что я могу работать на dev.example.com для сервера разработки (общего доступа) local.example. com для моего локального компьютера (и проверки локального кода других разработчиков) и www.example.com (или просто example.com) для живого сайта.

(Этот код находится в разделе «Настройки базы данных» файла settings.php):

$host = $_SERVER['HTTP_HOST'];
$base_url = 'http://'.$host;
$cookie_domain = $host;

switch($host) {
  case 'example.com': # Production server
    $db_url = 'mysqli://prod_sql_user:password@127.0.0.1/prod_db';
    $update_free_access = FALSE;
    $conf = array (
      // Set production config options here...
      'example_setting' => 0,
    );
    break;

  case 'dev.example.com': # Development server
    $db_url = 'mysqli://dev_sql_user:password@127.0.0.1/dev_db';
    $update_free_access = FALSE;
    $conf = array (
      // Set production config options here...
      'example_setting' => 0,
    );
    break;

  case 'local.example.com': # Local server
    $db_url = 'mysqli://local_sql_user:password@127.0.0.1/local_db';
    $update_free_access = FALSE;
    $conf = array (
      // Set production config options here...
      'example_setting' => 0,
      // Turn off most core caching.
      'cache_inc' => 'includes/cache.inc',
      'cache' => CACHE_DISABLED,
    );
    break;

}
?>

Это работает довольно хорошо для большинства целей, но это означает, что у нас есть много постороннего кода, сидящего в нашем общем файле settings.php ... есть ли лучший способ?

geerlingguy
источник
Вы должны использовать многопользовательское решение Drupal drupal.org/node/290768
sobi3ch

Ответы:

66

Я делю этот файл на settings.php и local.settings.php.

В конце settings.php есть следующий код:

if (file_exists(dirname(__FILE__) . '/local.settings.php')) {
  include dirname(__FILE__) . '/local.settings.php';
}

Локальный файл затем исключается из любой используемой вами VCS. Преимущество состоит в том, что вы можете помещать настройки, которые являются общими для всех экземпляров, в settings.php и автоматически обновлять их / распространять и сохранять локальный материал в local.settings.php.

Berdir
источник
2
Это на самом деле стратегия, используемая на самом drupal.org, и мы постоянно используем ее на Palantir.net. Для велосипеда я рекомендую использовать «settings.local.php» в качестве имени файла, поскольку оно соответствует шаблону, установленному «settings.default.php».
Дейв Рейд
1
Я создал суть для этого: gist.github.com/1235389, так как я использую это все чаще и чаще
chrisjlee
4
Примечание: Drupal 8 теперь добавил подобный фрагмент в файл настроек по умолчанию, вам просто нужно раскомментировать его: drupal.org/node/1118520
Berdir
1
@DaveReid: шаблон устанавливается в default.settings.php, а не в settings.default.php.
иконоборчество
1
Для забавы вы можете использовать (__DIR__)вместо dirname(__FILE__). Они эквивалентны .
cdmo
26

Похоже, вы заново изобретаете встроенную в Drupal функциональность.

Лично я держу все стандартные темы и модули для сайта sites/all, а потом уже sites/dev.example.comи sites/example.com.

В качестве дополнительного бонуса вы можете использовать разные filesпапки для каждого сайта, а также добавлять любые модули разработки sites/dev.example.com/modules.

Пол Джонс
источник
Это имеет некоторый смысл, но у меня есть несколько сайтов, где уже есть 5-10 многосайтовых папок, и наличие всех тем для этих сайтов в sites / all / themes может быть довольно раздражающим. Не говоря уже о моем типичном использовании custom.module для каждого сайта. Я думаю, что я мог бы использовать sitename_custom.module вместо: - /
geerlingguy
2
Вы всегда можете попробовать использовать символические ссылки из sites/dev.example.com/modulesкsites/example.com/modules
Пол Джонс
Принятие этого ответа - я собираюсь попробовать это на сайте, над которым я сейчас работаю. Похоже, хорошо подходит для моего рабочего процесса.
geerlingguy
9
Я думаю, что на самом деле это плохой способ работы с разработчиками и промежуточными средами, потому что они на самом деле не разные / отдельные сайты, а просто разные версии одного и того же сайта. В этом случае вы бы очень хотели избежать наличия отдельных файлов для каждого сайта. Я очень рекомендую использовать метод, упомянутый ниже, где settings.php является версионной, а настройки, специфичные для каждого сайта (настройки БД), помещаются в local.settings.php, который не версионирован.
Майки П
1
@Mikey P - оба решения верны - я думаю, что в основном это зависит от личных / командных предпочтений ... есть компромиссы с любым подходом, на мой взгляд.
geerlingguy
10

Я предпочитаю игнорировать файл локально (используя .gitignoreфайл в git), а затем хранить отдельные версии, если файл на каждом хосте.

извед
источник
1
Это интересное решение, хотя мне нравится отслеживать файлы settings.php в git (некоторые ошибки, которые я обнаружил, связаны с изменениями setting.php ...). Есть ли способ, которым я мог бы сделать так, чтобы моя локальная проверка на git заменила этот файл на мой (кроме того, что я скопировал в свой собственный файл)?
geerlingguy
1
Я тоже так делаю. Файлы с данными конфигурации, особенно с учетными данными базы данных, не имеют места в VCS.
Ммартинов
@geerlingguy да, вы можете. Пожалуйста, прочитайте мое обновление (если оно будет опубликовано;)
sobi3ch
@martin Я согласен, но давайте не будем забывать, что у нас может быть СПЕЦИАЛЬНОЕ отдельное репо только для ЭТОГО файла! Вы можете прочитать это в моем обновлении.
sobi3ch
7

Я склонен всегда настраивать записи файлов DNS или хоста и использовать

dev.example.com
staging.example.com

а также

example.com

Тогда у меня есть совершенно отдельные каталоги файлов настроек с разными каталогами файлов. Например ./sites/dev.example.com/files

Стюарт Робинсон
источник
Проблема, с которой я сталкиваюсь при таком подходе, состоит в том, что у меня часто есть каталог / themes / и / modules /, который я использую для каждого сайта (часто в многосайтовой настройке), и поскольку мне нужно использовать эти модули и темы, специфичные для сайта, для локальных , dev и production, я не могу просто сделать хосты / мультисайты такими: - /
geerlingguy
Хорошая точка зрения. Я полагаю, я пропустил эту символическую ссылку.
Стюарт Робинсон,
Таким способом вы можете создать символическую ссылку и поделиться папками тем и модулей. Таким образом, в основном ваша основная папка будет производственной папкой, а затем из нее вы сможете создать символические ссылки на stage, dev и local.
gansbrest
5

Почему бы не иметь несколько папок на основе имени хоста разработки?

пример

  • сайты / dev1.domain.com
  • сайты / dev2.domain.com
  • сайты / dev3.domain.com
  • сайты / www.domain.com

У каждого свой файл настроек и db_url.

Kevin
источник
Потенциальная проблема: файлы, сохраненные / загруженные в одной папке сайта, не будут доступны для другой.
Грег
Смотрите мой ответ @Stewart :)
geerlingguy
Создайте символические ссылки на центральную папку с файлами
Kevin
2

Если изменяются только учетные данные базы данных, то вы можете установить переменные окружения в своем локальном (и промежуточном / производственном) конфигурации виртуального хоста или в .htaccess папке выше вашего веб-корня. Вот простой пример:

/var/www/example.com/drupal-resides-here

Затем я могу создать файл .htaccess здесь:

/var/www/example.com/.htaccess

который имеет следующий код:

SetEnv DB1_USER my_local_user
SetEnv DB1_PASS my_local_pass
SetEnv DB1_HOST my_local_host
SetEnv DB1_NAME my_local_dbname

Затем в /var/www/example.com/drupal-resides-here/sites/default/settings.php(или как угодно) вы можете получить учетные данные БД, такие как:

$db_url = "mysql://{$_SERVER['DB1_USER']}:{$_SERVER['DB1_PASS']}@{$_SERVER['DB1_HOST']}:{$_SERVER['DB1_PORT']}/{$_SERVER['DB1_NAME']}";

Это позволяет нескольким разработчикам запускать вещи локально, и вы можете перейти к подготовке / производству, все еще отслеживая settings.php (там больше вещей, чем просто учетные данные базы данных ...). Вам также не придется отслеживать несколько файлов settings.php.

Чарли Шлиссер
источник
Я лично думаю, что это лучший путь. Однако в наших настройках мы добавляем операторы SetEnv в конфигурацию apache. Делает это немного более безопасным.
Скотт Джудри
Это интересное использование для .htaccess и хранения переменных. Но как насчет того, когда вы бежите drush up --y? Это перезапишет ваш базовый файл .htaccess.
Screenack
Это делается в .htaccessфайле на уровне выше webroot. Например, /var/www/.htaccessхранит эти директивы и /var/www/drupal/.htaccessбудет Drupal's .htaccess. Вы также можете просто поместить его в конфигурацию виртуального хоста Apache, что еще лучше. Независимо от всего этого, у нас почти всегда есть пользовательский материал в корне, .htaccessи поэтому, если мы обновляем Drupal, нам нужно сравнить .htaccessизменения с Git.
Чарли Шлиссер
0

Самое простое и эффективное решение, состоящее всего из одной строки, заключается в следующем. Просто включите его в последнюю строку вашего файла settings.php:

@include('settings.local.php');

Символ @ в начале означает, что ошибка не отображается, даже если он не находит этот файл. Типичные настройки, подобные этой, включают условную проверку наличия файла. Это выполняет это в одной строке без него.

http://php.net/manual/en/language.operators.errorcontrol.php

Также известен как оператор STFU PHP .

Патоши パ ト シ
источник
Просто, но я не считаю самым эффективным. seanmonstar.com/post/909029460/…
AyeshK