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

По сути, это один из величайших вопросов всех времен: каким образом вы используете 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 ... есть ли лучший способ?

Я делю этот файл на 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.

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

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

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

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

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

dev.example.com
staging.example.com

а также

example.com

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

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

пример

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

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

Если изменяются только учетные данные базы данных, то вы можете установить переменные окружения в своем локальном (и промежуточном / производственном) конфигурации виртуального хоста или в .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.

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

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

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

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

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