Vorschläge für die Einstellungen.php - Lokaler Dev, Entwicklungsserver, Live -Server
-
16-10-2019 - |
Frage
Grundsätzlich eine der größten Fragen aller Zeiten: Wie verwenden Sie Settings.php in Ihrem Entwicklungs-/Staging -Workflow?
Im Moment habe ich meine Einstellungen.Php -Datei wie folgt eingerichtet, und ich stütze meine Entwicklung auf der $ Host -Host -Anweisung des Servers - das Meaning kann auf dev.example.com für den Entwicklungsserver (Shared), Local.example, arbeiten. com für meinen lokalen Computer (und die lokalen Code -Checkouts eines anderen Entwicklers) 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 ziemlich gut für die meisten Zwecke, aber es bedeutet, dass wir in unserer Shared Setting.Php -Datei viele fremde Code haben ... Gibt es einen besseren Weg?
Lösung
Was ich tue, ist, diese Datei in eine Einstellungen zu trennen.Php und ein lokal.Settings.php.
Am Ende von Einstellungen.PHP befindet sich der folgende Code:
if (file_exists(dirname(__FILE__) . '/local.settings.php')) {
include dirname(__FILE__) . '/local.settings.php';
}
Die lokale Datei wird dann von den von Ihnen verwendeten VCs ausgeschlossen. Der Vorteil besteht darin, dass Sie Einstellungen einstellen können, die in allen Fällen in Settings.php üblich sind und diese automatisch verteilt/verteilt haben und die lokalen Dinge in Local.Setings.php behalten.
Andere Tipps
Dies scheint, als ob Sie Drupal neu in mehreren Funktionen in mehreren Unternehmen neu erfinden.
Persönlich halte ich alle Standardthemen und Module für die Website in sites/all
, und dann haben sites/dev.example.com
und sites/example.com
.
Als zusätzlichen Bonus können Sie dann anders haben files
Ordner für jede Website und Sie können alle Entwicklungsmodule hinzufügen sites/dev.example.com/modules
auch.
Ich ziehe es vor, die Datei lokal zu ignorieren (mit a .gitignore
Datei in Git) und dann separate Versionen beibehalten, wenn die Datei auf jedem Host.
Ich neige dazu, immer DNS oder Hostdateieinträge einzurichten und zu verwenden
dev.example.com
staging.example.com
und
example.com
Dann habe ich vollständig separate Einstellungsdateiverzeichnisse mit unterschiedlichen Dateienverzeichnissen. Zum Beispiel ./sites/dev.example.com/files
Warum nicht ein paar Ordner basierend auf dem Entwicklungshostnamen?
Beispiel
- Sites/dev1.domain.com
- Sites/dev2.domain.com
- Websites/dev3.domain.com
- Websites/www.domain.com
Jeweils mit ihrer eigenen Einstellungsdatei und db_url.
Wenn sich die einzigen Dinge ändern, sind die Datenbank -Anmeldeinformationen, dann können Sie Umgebungsvariablen in Ihrer lokalen (und Staging/Produktion) virtuellen Host -Konfiguration oder in einem .htaccess in einem 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 hat den folgenden Code:
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:
$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 die Dinge lokal ausführen und Sie können auf Staging / Produktion weitergeben, während Sie die Einstellungen.Php verfolgen (es gibt mehr Dinge da als nur die Datenbank -Anmeldeinformationen ...). Sie müssten auch mehrere Einstellungen.Php -Dateien nicht im Auge behalten.
Die einfachste und effizienteste Lösung, die nur eine Zeile ist, ist die folgende. Geben Sie es einfach in die letzte Zeile Ihrer Datei "setting.php" ein:
@include('settings.local.php');
Das @ -Symbol in der Vorderseite bedeutet nur, keinen Fehler anzuzeigen, auch wenn es diese Datei nicht findet. Typische Setups wie diese 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 die STFU PHP -Operator.