Sugestões para settings.php - desenvolvedor local, servidor de desenvolvimento, servidor ao vivo

Basicamente, uma das maiores perguntas de todos os tempos: quais são as maneiras pelas quais você usa o settings.php no seu fluxo de trabalho de desenvolvimento / preparação?

No momento, tenho meu arquivo settings.php configurado da seguinte maneira e baseio meu desenvolvimento na diretiva $ HOST do servidor - o que significa que posso trabalhar no dev.example.com para o servidor de desenvolvimento (compartilhado) local.example. com para o meu computador local (e check-out de código local de outros desenvolvedores) e www.example.com (ou apenas example.com) para o site ativo.

(Este código está na seção 'Configurações do banco de dados' do 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;

}
?>

Isso funciona muito bem para a maioria dos propósitos, mas significa que temos muitos códigos estranhos em nosso arquivo settings.php compartilhado ... existe uma maneira melhor?

O que faço é separar esse arquivo em um settings.php e um local.settings.php.

No final de settings.php está o seguinte código:

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

O arquivo local é excluído de qualquer VCS que você estiver usando. A vantagem é que você pode colocar configurações comuns em todas as instâncias em settings.php e ter essa versão / distribuição automaticamente e manter o material local em local.settings.php.

Parece que você está reinventando a funcionalidade multisite incorporada do Drupal.

Pessoalmente, mantenho todos os temas e módulos padrão do site sites/alle, em seguida, tenho sites/dev.example.come sites/example.com.

Como um bônus adicional, você pode ter filespastas diferentes para cada site e também adicionar quaisquer módulos de desenvolvimento sites/dev.example.com/modules.

Prefiro ignorar o arquivo localmente (usando um .gitignorearquivo no git) e, em seguida, manter versões separadas se o arquivo em cada host.

Costumo sempre configurar entradas de arquivos DNS ou host e usar

dev.example.com
staging.example.com

e

example.com

Então eu tenho diretórios de arquivos de configurações completamente separados com diretórios de arquivos diferentes. Por exemplo ./sites/dev.example.com/files

Por que não ter algumas pastas com base no nome do host de desenvolvimento?

Exemplo

• sites / dev1.domínio.com
• sites / dev2.domínio.com
• sites / dev3.domínio.com
• sites / www.domínio.com

Cada um com seu próprio arquivo de configurações e db_url.

Se as únicas coisas que mudam são as credenciais do banco de dados, você pode definir variáveis ​​de ambiente na configuração do host virtual local (e de preparação / produção) ou em um .htaccess uma pasta acima da raiz da web. Aqui está um exemplo simples:

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

Posso criar um arquivo .htaccess aqui:

/var/www/example.com/.htaccess

que tem o seguinte 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

Em /var/www/example.com/drupal-resides-here/sites/default/settings.php(ou seja o que for), você pode obter as credenciais do banco de dados como:

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

Isso permite que vários desenvolvedores executem as coisas localmente e você pode avançar para a preparação / produção enquanto ainda monitora o settings.php (há mais coisas lá do que apenas as credenciais do banco de dados ...). Você também não precisaria acompanhar vários arquivos settings.php.

A solução mais simples e eficiente, com apenas uma linha, é a seguinte. Basta incluí-lo na última linha do seu arquivo settings.php:

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

O símbolo @ na frente significa apenas não exibir nenhum erro, mesmo que ele não encontre esse arquivo. Configurações típicas como essa envolvem uma condição para verificar se o arquivo está lá. Isso é realizado em uma linha sem ele.

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

Também conhecido como operador STFU PHP .