it-swarm-es.com

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 las comprobaciones 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 muchos códigos extraños en nuestro archivo settings.php compartido ... ¿hay una mejor manera?

80
geerlingguy

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 tener eso versionado/distribuido automáticamente y mantener las cosas locales en local.settings.php.

66
Berdir

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

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

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

25
Paul Jones

Prefiero ignorar el archivo localmente (usando un .gitignore archivo en git) y luego mantenga versiones separadas si el archivo en cada Host.

10
ack

Tiendo a configurar siempre las entradas del archivo DNS o 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

6
Stewart Robinson

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

Ejemplo

  • sites/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.

5
Kevin

Si lo único que cambia son las credenciales de la base de datos, entonces 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 usted puede Empujar 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.

2

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 STFU PHP operador .

0