web-dev-qa-db-ja.com

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:[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;

}
?>

これはほとんどの目的でうまく機能しますが、共有のsettings.phpファイルに多くの無関係なコードが存在することを意味します...より良い方法はありますか？

workflowsconfiguration-managementstaging
80
geerlingguy

そのファイルを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に保持できることです。

66
Berdir

これは、Drupalの組み込みマルチサイト機能を再発明しているようです。

個人的には、サイトのすべての標準テーマとモジュールをsites/allに保持し、sites/dev.example.comとsites/example.comを使用しています。

追加のボーナスとして、サイトごとに異なるfilesフォルダーを作成できます。また、開発モジュールをsites/dev.example.com/modulesに追加することもできます。

25
Paul Jones

ローカルでファイルを無視したい（.gitignore file in git）、各ホストにファイルがある場合は、個別のバージョンを保持します。

10
ack

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

dev.example.com
staging.example.com

そして

example.com

次に、設定ファイルのディレクトリが完全に分かれており、ファイルディレクトリが異なります。たとえば./sites/dev.example.com/files

6
Stewart Robinson

開発ホスト名に基づいたいくつかのフォルダーがないのはなぜですか？

例

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

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

5
Kevin

変更するのがデータベース資格情報のみである場合は、ローカル（およびステージング/本番）仮想ホスト構成、または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ファイルを追跡する必要もありません。

2
Charlie Schliesser

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

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

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

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

STFU PHP operatorとも呼ばれます。

0
Patoshi パトシ