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 meine Entwicklung basiert auf der $ HOST-Direktive des Servers - das heißt, ich kann auf dev.example.com für den (gemeinsam genutzten) Entwicklungsserver local.example arbeiten. com für meinen lokalen Computer (und die lokalen Code-Checkouts anderer Entwickler) und www.example.com (oder nur 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: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;

}
?>

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

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 ablegen und diese automatisch versionieren / verteilen lassen und die lokalen Inhalte in local.settings.php behalten können.

Anscheinend erfinden Sie die integrierte Multisite-Funktionalität von Drupal neu.

Persönlich behalte ich alle Standardthemen und -module für die Site bei sites/allund habe dann sites/dev.example.comund sites/example.com.

Als zusätzlichen Bonus können Sie dann verschiedene filesOrdner für jede Site haben und Sie können auch beliebige Entwicklungsmodule hinzufügen sites/dev.example.com/modules.

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

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 getrennte Einstellungsdateiverzeichnisse mit unterschiedlichen Dateiverzeichnissen. Zum Beispiel ./sites/dev.example.com/files

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

Beispiel

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

Jede mit ihrer eigenen Einstellungsdatei und db_url.

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 können Sie in /var/www/example.com/drupal-resides-here/sites/default/settings.php(oder was auch immer) 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 auf Staging / Produktion umsteigen, während Sie die settings.php verfolgen (es sind mehr Dinge enthalten als nur die Datenbankanmeldeinformationen ...). Sie müssten auch nicht mehrere settings.php-Dateien im Auge behalten.

Die einfachste und effizienteste Lösung, bei der es sich nur um eine Zeile handelt, ist die folgende. Fügen Sie es einfach in die letzte Zeile Ihrer settings.php-Datei ein:

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

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

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

Wird auch als STFU-PHP-Operator bezeichnet .