web-dev-qa-db-fra.com

Suggestions pour settings.php - Dev local, serveur de développement, serveur Live

Fondamentalement, l'une des plus grandes questions de tous les temps: comment utilisez-vous settings.php dans votre flux de travail de développement/mise en scène?

À l'heure actuelle, mon fichier settings.php est configuré comme suit, et je base mon développement sur la directive $ Host du serveur, ce qui signifie que je peux travailler sur dev.example.com pour le serveur de développement (partagé), local.example. com pour mon ordinateur local (et les vérifications de code local d'autres développeurs), et www.example.com (ou simplement example.com) pour le site en direct.

(Ce code se trouve dans la section "Paramètres de la base de données" de 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;

}
?>

Cela fonctionne assez bien dans la plupart des cas, mais cela signifie que nous avons beaucoup de code superflu dans notre fichier settings.php partagé ... y a-t-il une meilleure façon?

workflowsconfiguration-managementstaging
80
geerlingguy

Ce que je fais, c'est séparer ce fichier en settings.php et local.settings.php.

À la fin de settings.php se trouve le code suivant:

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

Le fichier local est ensuite exclu de tout VCS que vous utilisez. L'avantage est que vous pouvez mettre des paramètres qui sont communs à toutes les instances dans settings.php et les faire versionner/distribuer automatiquement et conserver les éléments locaux dans local.settings.php.

66
Berdir

Il semble que vous réinventiez la fonctionnalité multisite intégrée de Drupal.

Personnellement, je conserve tous les thèmes et modules standard du site dans sites/all, puis avoir sites/dev.example.com et sites/example.com.

En prime, vous pouvez alors avoir différents dossiers files pour chaque site, et vous pouvez ajouter n'importe quel module de développement à sites/dev.example.com/modules ainsi que.

25
Paul Jones

Je préfère ignorer le fichier localement (en utilisant un .gitignore fichier dans git), puis conservez des versions distinctes si le fichier est sur chaque hôte.

10
ack

J'ai tendance à toujours configurer des entrées de fichier DNS ou hôte et à utiliser

dev.example.com
staging.example.com

et

example.com

Ensuite, j'ai des répertoires de fichiers de paramètres complètement séparés avec des répertoires de fichiers différents. Par exemple ./sites/dev.example.com/files

6
Stewart Robinson

Pourquoi ne pas avoir quelques dossiers basés sur le nom d'hôte de développement?

Exemple

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

Chacun avec son propre fichier de paramètres et db_url.

5
Kevin

Si les seules choses qui changent sont les informations d'identification de la base de données, vous pouvez définir des variables d'environnement dans votre configuration d'hôte virtuel local (et de transfert/production) ou dans un .htaccess un dossier au-dessus de votre racine Web. Voici un exemple simple:

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

Je peux ensuite créer un fichier .htaccess ici:

/var/www/example.com/.htaccess

qui a le code suivant:

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

Puis dans /var/www/example.com/drupal-resides-here/sites/default/settings.php (ou autre), vous pouvez récupérer les informations d'identification de la base de données comme:

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

Cela permet à plusieurs développeurs d'exécuter des choses localement et vous pouvez pousser vers la mise en scène/production tout en continuant à suivre settings.php (il y a plus de choses que juste les informations d'identification de la base de données ...). Vous n'auriez pas non plus à garder une trace de plusieurs fichiers settings.php.

2
Charlie Schliesser

La solution la plus simple et la plus efficace qui n'est qu'une seule ligne est la suivante. Il suffit de l'inclure dans la dernière ligne de votre fichier settings.php:

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

Le symbole @ à l'avant signifie simplement qu'il n'affiche aucune erreur même s'il ne trouve pas ce fichier. Les configurations typiques comme celle-ci impliquent une conditionnelle pour vérifier si le fichier est là. Cela l'accomplit en une seule ligne sans lui.

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

Également connu sous le nom STFU PHP .

0
Patoshi パトシ