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

80

En gros, l’une des plus grandes questions de tous les temps: comment utilisez-vous settings.php dans votre flux de travail de développement / staging?

À l'heure actuelle, j'ai le fichier settings.php 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 extractions de code local des autres développeurs), et www.example.com (ou tout simplement exemple.com) pour le site actif.

(Ce code se trouve dans la section "Paramètres de 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 plutôt bien dans la plupart des cas, mais cela signifie que nous avons beaucoup de code étranger dans notre fichier settings.php partagé ... existe-t-il un meilleur moyen?

Geerlingguy
la source
Vous devez utiliser la solution multi-site Drupal drupal.org/node/290768
sobi3ch

Réponses:

66

Ce que je fais est de séparer ce fichier en un fichier settings.php et un fichier 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 du VCS que vous utilisez. L'avantage est que vous pouvez définir des paramètres communs à toutes les instances du fichier settings.php, les transférer automatiquement versionnés / versionnés et conserver le contenu local dans le fichier local.settings.php.

Berdir
la source
2
C'est en fait la stratégie utilisée sur drupal.org et que nous utilisons systématiquement sur Palantir.net. Pour un bikeshed, je recommande d'utiliser "settings.local.php" comme nom de fichier car il correspond au modèle défini par "settings.default.php".
Dave Reid
1
J'ai créé un résumé pour cela: gist.github.com/1235389 depuis que je l'utilise de plus en plus fréquemment
chrisjlee le
4
Remarque: Drupal 8 a maintenant ajouté un extrait similaire au fichier de paramètres par défaut. Il vous suffit de le commenter
Berdir
1
@DaveReid: le modèle est défini par ' default.settings.php ' et non par 'settings.default.php'.
iconoclast
1
Pour les amusements, vous pouvez utiliser (__DIR__)au lieu de dirname(__FILE__). Ils sont équivalents .
Cdmo
26

On dirait que vous réinventez la fonctionnalité multisite intégrée de Drupal.

Personnellement, je conserve tous les thèmes et modules standard du site sites/all, puis j'ai sites/dev.example.comet sites/example.com.

En prime, vous pouvez avoir différents filesdossiers pour chaque site et vous pouvez également ajouter des modules de développement sites/dev.example.com/modules.

Paul Jones
la source
Cela a du sens, mais il existe quelques sites sur lesquels il existe déjà 5 à 10 dossiers multisites, et avoir tous les thèmes de ces sites dans sites / all / themes peut être assez ennuyeux. Sans parler de mon utilisation typique de custom.module pour chaque site. Je suppose que je pourrais utiliser sitename_custom.module à la place: - /
geerlingguy
2
Vous pouvez toujours essayer d' utiliser des liens symboliques de l' sites/dev.example.com/modulesàsites/example.com/modules
Jones Paul
Accepter cette réponse - Je vais essayer ceci sur le site sur lequel je travaille actuellement. Cela convient bien à mon flux de travail.
geerlingguy
9
Je pense que c'est en fait une mauvaise façon de gérer les environnements de développement et de transfert, car ils ne sont pas réellement différents / sites distincts, mais simplement des versions différentes du même site. Dans ce cas, vous voudrez certainement éviter d’avoir des fichiers séparés pour chaque site. Je vous recommande vivement d'utiliser la méthode mentionnée ci-dessous, où settings.php est versionné et les paramètres spécifiques à chaque site (paramètres de base de données) sont placés dans un fichier local.settings.php qui n'est pas versionné.
Mikey P
1
@ Mikey P - les deux solutions sont valables - je pense que cela dépend principalement des préférences personnelles / de l'équipe ici ... il y a des compromis entre les deux approches, à mon avis.
geerlingguy
10

Je préfère ignorer le fichier localement (à l'aide d'un .gitignorefichier dans git), puis conserver des versions distinctes du fichier sur chaque hôte.

ack
la source
1
C’est une solution intéressante, même si j’aime bien suivre les paramètres.php dans git (certains bugs que j’ai rencontrés sont dus à des modifications de setting.php ...). Existe-t-il un moyen de faire en sorte que ma caisse locale git remplace ce fichier par le mien (en plus de me le copier dans mon propre fichier)?
geerlingguy
1
C'est ce que je fais aussi. Les fichiers contenant des données de configuration, en particulier les informations d'identification de la base de données, n'ont pas de place dans le VCS.
mmartinov
@geerlingguy oui vous pouvez. S'il vous plaît lire ma mise à jour (si elle sera publiée;)
sobi3ch
@martin Je suis d'accord, mais n'oublions pas que nous pouvons avoir un dépôt séparé SPÉCIAL uniquement pour CE fichier! Vous pouvez le lire dans ma mise à jour.
sobi3ch
7

J'ai tendance à toujours configurer les entrées de fichier DNS ou hôte et les 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

Stewart Robinson
la source
Le problème que je vois avec cette approche est que j’ai souvent un répertoire / themes / et / modules / que j’utilise pour chaque site (souvent dans une configuration multisite), et que j’ai besoin d’utiliser ces modules et thèmes spécifiques au site pour des applications locales. , dev et production, je ne peux pas faire des hôtes / multisites comme ça: - /
geerlingguy
Bon point. Je suppose que j'ai laissé de côté que je symlink ce truc
Stewart Robinson
Vous pouvez créer un lien symbolique et partager ainsi des dossiers de thèmes et de modules. Donc, fondamentalement, votre dossier principal sera un dossier de production et vous pourrez ensuite créer un lien symbolique vers stage et dev et local.
Gansbrest
5

Pourquoi ne pas avoir quelques dossiers basés sur le nom de l'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.

Kevin
la source
Problème potentiel: les fichiers enregistrés / téléchargés dans un dossier de site ne seront pas accessibles à un autre.
Greg
Voir ma réponse à @Stewart :)
geerlingguy
Créez des liens symboliques vers le dossier de fichiers central
Kevin
2

Si les seules informations 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 stockage intermédiaire / de production) ou dans un dossier .htaccess situé 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

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

$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 tâches localement et de passer au paramétrage / production tout en continuant de suivre settings.php (il ne contient pas uniquement les informations d'identification de la base de données ...). Vous ne devez pas non plus garder trace de plusieurs fichiers settings.php.

Charlie Schliesser
la source
Personnellement, je pense que c'est la meilleure voie à suivre. Cependant, notre configuration ajoute les instructions SetEnv à la configuration d'Apache. Le rend un peu plus sécurisé.
Scott Joudry
C'est une utilisation intéressante pour .htaccess et le stockage variable. Mais qu'en est-il quand tu cours drush up --y? Cela écrasera votre fichier .htaccess de base.
Screenack
Cela se fait dans un .htaccessfichier d'un niveau supérieur à webroot. Par exemple, /var/www/.htaccessstocke ces directives et /var/www/drupal/.htaccessserait celles de Drupal .htaccess. Vous pouvez aussi simplement le mettre dans la configuration de l'hôte virtuel Apache, ce qui est encore mieux. Indépendamment de cela, nous avons presque toujours des éléments personnalisés dans la racine du site Web. Par .htaccessconséquent, si nous mettons à jour Drupal, nous devons comparer les .htaccessmodifications apportées à celles de Git.
Charlie Schliesser
0

La solution la plus simple et la plus efficace qui n’est qu’une ligne est la suivante. Incluez-le simplement dans la dernière ligne de votre fichier settings.php:

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

Le symbole @ à l'avant signifie simplement que vous ne voyez aucune erreur même s'il ne trouve pas ce fichier. Les configurations typiques comme celle-ci impliquent une condition pour vérifier si le fichier est là. Cela le fait en une ligne sans lui.

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

Également appelé opérateur PHP STFU .

Patoshi ト シ
la source
Simple, mais je ne pense pas le plus efficace. seanmonstar.com/post/909029460/…
AyeshK