it-swarm.com.de

Vorschläge für settings.php - Lokaler Entwickler, Entwicklungsserver, Live-Server

Grundsätzlich eine der größten Fragen aller Zeiten: Wie verwenden Sie settings.php in Ihrem Entwicklungs-/Staging-Workflow?

Im Moment habe ich meine settings.php-Datei wie folgt eingerichtet und stütze meine Entwicklung auf die $ Host-Direktive des Servers. Dies bedeutet, dass ich auf dev.example.com für den (gemeinsam genutzten) Entwicklungsserver local.example arbeiten kann. com für meinen lokalen Computer (und die lokalen Code-Kassen anderer Entwickler) und www.example.com (oder einfach example.com) für die Live-Site.

(Dieser Code befindet sich im Abschnitt 'Datenbankeinstellungen' von 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;

}
?>

Dies funktioniert für die meisten Zwecke ziemlich gut, aber es bedeutet, dass in unserer gemeinsam genutzten settings.php-Datei viel fremder Code herumsteht ... gibt es einen besseren Weg?

80
geerlingguy

Ich trenne diese Datei in eine settings.php und eine local.settings.php.

Am Ende von settings.php steht der folgende Code:

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

Die lokale Datei wird dann von dem von Ihnen verwendeten VCS ausgeschlossen. Der Vorteil ist, dass Sie Einstellungen, die für alle Instanzen gleich sind, in settings.php einfügen und diese automatisch versionieren/verteilen lassen und die lokalen Inhalte in local.settings.php behalten können.

66
Berdir

Dies scheint, als würden Sie die integrierte Multisite-Funktionalität von Drupal neu erfinden.

Persönlich behalte ich alle Standardthemen und -module für die Site in sites/all Und habe dann sites/dev.example.com Und sites/example.com.

Als zusätzlichen Bonus können Sie dann für jede Site unterschiedliche files Ordner haben und Sie können auch beliebige Entwicklungsmodule zu sites/dev.example.com/modules Hinzufügen.

25
Paul Jones

Ich bevorzuge es, die Datei lokal zu ignorieren (mit einem .gitignore Datei in Git) und behalten Sie dann separate Versionen, wenn die Datei auf jedem Host.

10
ack

Ich neige dazu, immer DNS- oder Host-Dateieinträge einzurichten und zu verwenden

dev.example.com
staging.example.com

und

example.com

Dann habe ich völlig separate Einstellungsdateiverzeichnisse mit unterschiedlichen Dateiverzeichnissen. Zum Beispiel ./sites/dev.example.com/files

6

Warum nicht ein paar Ordner basierend auf dem Namen des Entwicklungshosts?

Beispiel

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

Jedes mit seiner eigenen Einstellungsdatei und db_url.

5
Kevin

Wenn sich nur die Datenbankanmeldeinformationen ändern, können Sie Umgebungsvariablen in Ihrer lokalen (und Staging-/Produktions-) virtuellen Hostkonfiguration oder in einem .htaccess-Ordner über Ihrem Webstamm festlegen. Hier ist ein einfaches Beispiel:

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

Ich kann dann hier eine .htaccess-Datei erstellen:

/var/www/example.com/.htaccess

welches den folgenden Code hat:

SetEnv DB1_USER my_local_user
SetEnv DB1_PASS my_local_pass
SetEnv DB1_Host my_local_Host
SetEnv DB1_NAME my_local_dbname

Dann in /var/www/example.com/drupal-resides-here/sites/default/settings.php (oder was auch immer) Sie können die DB-Anmeldeinformationen wie folgt abrufen:

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

Auf diese Weise können mehrere Entwickler Dinge lokal ausführen und Sie können zu Staging/Produktion wechseln, während Sie weiterhin settings.php verfolgen (dort sind mehr Dinge als nur die Datenbankanmeldeinformationen ...). Sie müssten auch nicht mehrere settings.php-Dateien im Auge behalten.

2

Die einfachste und effizienteste Lösung, die nur aus einer Zeile besteht, ist die folgende. Fügen Sie es einfach in die letzte Zeile Ihrer settings.php-Datei ein:

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

Das @ -Symbol vorne bedeutet nur, dass kein Fehler angezeigt wird, auch wenn diese Datei nicht gefunden wird. Typische Setups wie dieses beinhalten eine Bedingung, um zu überprüfen, ob die Datei vorhanden ist. Dies erreicht es in einer Zeile ohne es.

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

Auch bekannt als STFU PHP Operator .

0