Sugerencias para settings.php: desarrollo local, servidor de desarrollo, servidor en vivo

Básicamente, una de las preguntas más importantes de todos los tiempos: ¿Cuáles son algunas de las formas en que usa settings.php en su flujo de trabajo de desarrollo / preparación?

En este momento, tengo mi archivo settings.php configurado de la siguiente manera, y baso mi desarrollo en la directiva $ HOST del servidor, lo que significa que puedo trabajar en dev.example.com para el servidor de desarrollo (compartido), local.example. com para mi computadora local (y el pago de código local de otros desarrolladores) y www.example.com (o simplemente example.com) para el sitio en vivo.

(Este código se encuentra en la sección 'Configuración de la base de datos' 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;

}
?>

Esto funciona bastante bien para la mayoría de los propósitos, pero significa que tenemos un montón de código extraño en nuestro archivo settings.php compartido ... ¿hay una mejor manera?

Lo que hago es separar ese archivo en settings.php y local.settings.php.

Al final de settings.php se encuentra el siguiente código:

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

El archivo local se excluye de cualquier VCS que esté utilizando. La ventaja es que puede poner configuraciones que son comunes en todas las instancias en settings.php y tenerlas versionadas / distribuidas automáticamente y mantener las cosas locales en local.settings.php.

Parece que está reinventando la funcionalidad multisitio integrada de Drupal.

Personalmente, guardo todos los temas y módulos estándar para el sitio sites/all, y luego tengo sites/dev.example.comy sites/example.com.

Como filesbeneficio adicional, puede tener diferentes carpetas para cada sitio, y también puede agregar cualquier módulo de desarrollo sites/dev.example.com/modules.

Prefiero ignorar el archivo localmente (usando un .gitignorearchivo en git) y luego mantener versiones separadas si el archivo en cada host.

Siempre tiendo a configurar DNS o entradas de archivos de host y uso

dev.example.com
staging.example.com

y

example.com

Luego tengo directorios de archivos de configuración completamente separados con diferentes directorios de archivos. Por ejemplo ./sites/dev.example.com/files

¿Por qué no tener algunas carpetas basadas en el nombre del host de desarrollo?

Ejemplo

• sitios / dev1.domain.com
• sitios / dev2.domain.com
• sitios / dev3.domain.com
• sitios / www.dominio.com

Cada uno con su propio archivo de configuración y db_url.

Si lo único que cambia son las credenciales de la base de datos, puede establecer variables de entorno en su configuración de host virtual local (y preparación / producción) o en una carpeta .htaccess sobre su raíz web. Aquí hay un ejemplo simple:

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

Entonces puedo crear un archivo .htaccess aquí:

/var/www/example.com/.htaccess

que tiene el siguiente código:

SetEnv DB1_USER my_local_user
SetEnv DB1_PASS my_local_pass
SetEnv DB1_HOST my_local_host
SetEnv DB1_NAME my_local_dbname

Luego, en /var/www/example.com/drupal-resides-here/sites/default/settings.php(o lo que sea) puede obtener las credenciales de db como:

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

Esto permite que varios desarrolladores ejecuten cosas localmente y puede avanzar a la puesta en escena / producción mientras sigue rastreando settings.php (hay más cosas allí que solo las credenciales de la base de datos ...). Tampoco tendría que realizar un seguimiento de múltiples archivos settings.php.

La solución más simple y eficiente que es solo una línea es la siguiente. Simplemente inclúyalo en la última línea de su archivo settings.php:

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

El símbolo @ en el frente solo significa que no muestra ningún error, incluso si no encuentra ese archivo. Las configuraciones típicas como esta implican un condicional para verificar si el archivo está allí. Esto lo logra en una línea sin él.

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

También conocido como el operador PHP STFU .