Sugestie dotyczące ustawień.php - Lokalne oprogramowanie, serwer programistyczny, serwer na żywo

Zasadniczo jedno z największych pytań wszechczasów: w jaki sposób korzystasz z settings.php w procesie projektowania / przemieszczania?

W tej chwili mam skonfigurowany mój plik settings.php i opieram swój rozwój na dyrektywie $ HOST serwera - co oznacza, że ​​mogę pracować na dev.example.com dla serwera programistycznego (udostępnionego), local.example. com na moim komputerze lokalnym (i kasach lokalnych deweloperów) oraz www.example.com (lub po prostu example.com) na stronie na żywo.

(Ten kod znajduje się w sekcji „Ustawienia bazy danych” w pliku 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:[email protected]/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:[email protected]/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:[email protected]/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;

}
?>

Działa to całkiem dobrze do większości celów, ale oznacza to, że mamy dużo obcego kodu siedzącego w naszym wspólnym pliku settings.php ... czy jest lepszy sposób?

To, co robię, to rozdzielenie tego pliku na plik settings.php i plik local.settings.php.

Na końcu settings.php znajduje się następujący kod:

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

Plik lokalny jest następnie wykluczony z jakiegokolwiek używanego VCS. Zaletą jest to, że możesz umieszczać ustawienia, które są wspólne dla wszystkich instancji w pliku settings.php i mieć taką wersję / automatycznie dystrybuowaną oraz przechowywać lokalne rzeczy w pliku local.settings.php.

Wygląda na to, że wymyślasz na nowo wbudowaną funkcjonalność Drupala w wielu miejscach.

Osobiście przechowuję wszystkie standardowe motywy i moduły witryny sites/all, a następnie mam sites/dev.example.comi sites/example.com.

Jako dodatkowy bonus możesz mieć różne filesfoldery dla każdej strony, a także dodać dowolne moduły programistyczne sites/dev.example.com/modules.

Wolę zignorować plik lokalnie (używając .gitignorepliku w git), a następnie zachować osobne wersje, jeśli plik na każdym hoście.

Zazwyczaj zawsze konfiguruję wpisy DNS lub plików hosta i używam ich

dev.example.com
staging.example.com

i

example.com

Następnie mam całkowicie oddzielne katalogi plików ustawień z różnymi katalogami plików. Na przykład ./sites/dev.example.com/files

Dlaczego nie mieć kilku folderów opartych na nazwie hosta programistycznego?

Przykład

• sites / dev1.domain.com
• sites / dev2.domain.com
• sites / dev3.domain.com
• witryn / www.domain.com

Każdy z własnym plikiem ustawień i db_url.

Jeśli jedyne rzeczy, które się zmieniają, to poświadczenia bazy danych, możesz ustawić zmienne środowiskowe w lokalnej (i tymczasowej / produkcyjnej) konfiguracji hosta wirtualnego lub w .htaccess folderze powyżej głównego katalogu głównego. Oto prosty przykład:

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

Następnie mogę utworzyć tutaj plik .htaccess:

/var/www/example.com/.htaccess

który ma następujący kod:

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

Następnie w /var/www/example.com/drupal-resides-here/sites/default/settings.php(lub cokolwiek) możesz pobrać poświadczenia bazy danych, takie jak:

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

Dzięki temu wielu programistów może uruchamiać rzeczy lokalnie, a Ty możesz przejść do etapu / produkcji przy jednoczesnym śledzeniu ustawień. Php (jest tam więcej rzeczy niż tylko poświadczenia bazy danych ...). Nie musisz również śledzić wielu plików settings.php.

Najprostsze i najbardziej wydajne rozwiązanie składające się tylko z jednej linii jest następujące. Po prostu umieść go w ostatnim wierszu pliku settings.php:

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

Symbol @ z przodu oznacza po prostu nie wyświetlaj żadnego błędu, nawet jeśli nie znajdzie on tego pliku. Typowe ustawienia tego typu wymagają warunkowego sprawdzenia, czy plik tam jest. Osiąga to w jednym wierszu bez niego.

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

Znany również jako operator PHP STFU .