settings.phpの提案-ローカル開発者、開発サーバー、ライブサーバー

基本的に、これまでで最も大きな質問の1つです。開発/ステージングワークフローでsettings.phpを使用する方法は何ですか？

現在、settings.phpファイルは次のように設定されており、サーバーの$ HOSTディレクティブに基づいて開発を行っています。つまり、開発（共有）サーバーlocal.exampleのdev.example.comで作業できます。ローカルコンピューター（および他の開発者のローカルコードチェックアウト）には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ます。

ローカルでファイルを無視し（.gitignoregitのファイルを使用）、各ホストにファイルがある場合は別々のバージョンを保持することを好みます。

私は常にDNSまたはホストファイルエントリを設定して使用する傾向があります

dev.example.com
staging.example.com

そして

example.com

次に、異なるファイルディレクトリを持つ完全に独立した設定ファイルディレクトリがあります。たとえば、。/ sites / dev.example.com / files

開発ホスト名に基づいていくつかのフォルダーを作成しないのはなぜですか？

例

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

それぞれに独自の設定ファイルとdb_urlがあります。

データベース資格情報のみが変更される場合は、ローカル（およびステージング/本番）仮想ホスト構成またはWebルートの上の.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']}";

これにより、複数の開発者がローカルで物事を実行できるようになり、settings.phpを追跡しながらステージング/プロダクションにプッシュできます（データベースの資格情報以外にもあります...）。また、複数のsettings.phpファイルを追跡する必要もありません。

1行だけの最も簡単で効率的なソリューションは次のとおりです。settings.phpファイルの最後の行にそれを含めるだけです：

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

先頭の@記号は、そのファイルが見つからなくてもエラーを表示しないことを意味します。このような一般的なセットアップには、ファイルが存在するかどうかを確認する条件が含まれます。これにより、それなしで1行で実行できます。

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

STFU PHP演算子とも呼ばれます。