Пропозиції щодо settings.php - Локальний розробник, сервер розвитку, сервер Live

В основному, одне з найважливіших питань усіх часів: якими способами ви користуєтеся 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 на зразок:

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

Це дозволяє декільком розробникам запускати речі локально, і ви можете перейти до інсценізації / виготовлення, відстежуючи налаштування.php (там є більше речей, ніж просто дані бази даних ...). Вам також не доведеться відслідковувати кілька файлів settings.php.

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

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

Символ @ спереду просто означає, що не відображається жодна помилка, навіть якщо він не знайде цей файл. Типові налаштування на зразок цього передбачають умовну перевірку наявності файлу. Це виконує його в один рядок без нього.

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

Також відомий як оператор PHP STFU .