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

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?

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.

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.

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.

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

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.

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.

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 .