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


80

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:password@127.0.0.1/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:password@127.0.0.1/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:password@127.0.0.1/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?


Você deve usar o Drupal solução multi-site drupal.org/node/290768
sobi3ch

Respostas:


66

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.


2
Essa é realmente a estratégia usada no próprio drupal.org e usamos de forma consistente no Palantir.net. Para um ciclista, eu recomendo usar 'settings.local.php' como o nome do arquivo, pois ele corresponde ao padrão definido por 'settings.default.php'.
Dave Reid

1
Eu criei uma essência para isso: gist.github.com/1235389 desde que eu tenho usado isso mais e mais frequentemente
chrisjlee

4
Nota: Drupal 8 tem adicionado agora um trecho semelhante ao arquivo de configurações por padrão, você só precisa descomente-lo: drupal.org/node/1118520
Berdir

1
@DaveReid: o padrão é definido por ' default.settings.php ' e não por 'settings.default.php'.
Iconoclast

1
Para diversão, você pode usar em (__DIR__)vez de dirname(__FILE__). Eles são equivalentes .
cdmo

26

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.


Isso faz algum sentido, mas eu tenho alguns sites onde já existem de 5 a 10 pastas multisite, e ter todos os temas desses sites em sites / all / themes pode ser bastante irritante. Sem mencionar meu uso típico de custom.module para cada site. Eu acho que eu poderia usar sitename_custom.module em vez disso: - /
geerlingguy 2/11

2
Você sempre pode tentar usar links simbólicos do sites/dev.example.com/modulesparasites/example.com/modules
Paul Jones

Aceitando esta resposta - vou tentar isso no site em que estou trabalhando. Parece um bom ajuste para o meu fluxo de trabalho.
precisa saber é o seguinte

9
Acho que essa é realmente uma maneira ruim de lidar com ambientes de desenvolvimento e preparação, porque na verdade não são sites diferentes / separados, apenas versões diferentes do mesmo site. Nesse caso, você deseja evitar arquivos separados para cada site. Eu recomendo usar o método mencionado abaixo, em que settings.php é versionado e configurações específicas para cada site (configurações de banco de dados) são colocadas em um local.settings.php que não é versionado.
Mikey P

1
@ Mike P - ambas as soluções são válidas - acho que depende principalmente da preferência pessoal / da equipe aqui ... na minha opinião, existem vantagens e desvantagens em ambas as abordagens.
precisa saber é o seguinte

10

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


1
Esta é uma solução interessante, embora eu goste de acompanhar o settings.php no git (alguns bugs que tive surgiram devido a alterações no setting.php ...). Existe uma maneira de que meu check-out git local substitua esse arquivo pelo meu (além de me copiar no meu próprio arquivo)?
precisa saber é o seguinte

1
É o que eu também faço. Arquivos com dados de configuração, especialmente com credenciais de banco de dados, não têm lugar no VCS.
mmartinov

@geerlingguy sim você pode. Por favor, leia o meu update (se ele vai ser publicado;)
sobi3ch

@martin Eu concordo, mas não vamos esquecer que podemos ter repositórios separados especiais apenas para ESTE arquivo! Você pode lê-lo na minha atualização.
Sobi3ch

7

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


O problema que vejo com essa abordagem é que geralmente tenho um diretório / themes / e / modules / que eu uso para cada site (geralmente em uma configuração multisite), e como preciso usar esses módulos e temas específicos do site para locais , dev e produção, não posso apenas fazer anfitriões / multisite assim: - /
geerlingguy

Bom ponto. Eu acho que deixei de fora que eu associo essas coisas.
Stewart Robinson #

Você pode criar um link simbólico e compartilhar pastas de temas e módulos dessa maneira. Então, basicamente, sua pasta principal será uma pasta de produção e, a partir dela, você poderá criar links simbólicos para o estágio, dev e local.
precisa saber é o seguinte

5

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.


Problema potencial: os arquivos salvos / carregados em uma pasta do site não estarão acessíveis para outra.
Greg

Veja minha resposta a @Stewart :)
geerlingguy

Crie links simbólicos para a pasta de arquivos central
Kevin

2

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.


Pessoalmente, acho que esse é o melhor caminho a percorrer. No entanto, em nossa configuração, adicionamos as instruções SetEnv à configuração do apache. Torna um pouco mais seguro.
Scott Joudry

Esse é um uso interessante para .htaccess e armazenamento variável. Mas e quando você corre drush up --y? Isso substituirá o arquivo .htaccess básico.
Screenack

Isso é feito em um .htaccessarquivo acima do webroot. Por exemplo, /var/www/.htaccessarmazena essas diretivas e /var/www/drupal/.htaccessseria do Drupal .htaccess. Você também pode colocá-lo na configuração do host virtual Apache, que é ainda melhor. Independentemente disso, quase sempre temos coisas personalizadas no raiz da web .htaccesse, portanto, se atualizarmos o Drupal, precisamos comparar as .htaccessalterações com o Git.
Charlie Schliesser

0

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 .


Simples, mas não acho o mais eficiente. seanmonstar.com/post/909029460/…
AyeshK
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.