Saran untuk settings.php - Pengembang lokal, Server pengembangan, Server langsung


Pada dasarnya, salah satu pertanyaan terbesar sepanjang masa: Apa saja cara Anda menggunakan settings.php dalam alur kerja pengembangan / pementasan Anda?

Saat ini, saya mengatur file setting.php saya seperti berikut, dan saya mendasarkan pengembangan saya pada direktif $ HOST server — artinya saya dapat bekerja di dev.example.com untuk server pengembangan (dibagi), local.example. com untuk komputer lokal saya (dan checkout kode lokal dev lainnya), dan www.example.com (atau hanya example.com) untuk situs langsung.

(Kode ini ada di bagian 'Pengaturan basis data' pada 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;

}
?>

Ini berfungsi cukup baik untuk sebagian besar tujuan, tetapi itu berarti kita memiliki banyak kode asing yang terdapat di file shared.php yang kita bagikan ... apakah ada cara yang lebih baik?


Anda harus menggunakan Drupal multi-site solution drupal.org/node/290768
sobi3ch

Jawaban:


Apa yang saya lakukan adalah memisahkan file itu menjadi settings.php dan local.settings.php.

Di akhir settings.php adalah kode berikut:

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

File lokal kemudian dikeluarkan dari VCS apa pun yang Anda gunakan. Keuntungannya adalah Anda dapat meletakkan pengaturan yang umum di atas semua instance di settings.php dan membuat versi / didistribusikan secara otomatis dan menyimpan barang-barang lokal di local.settings.php.


2
Ini sebenarnya adalah strategi yang digunakan pada drupal.org itu sendiri dan kami gunakan secara konsisten di Palantir.net. Untuk bikeshed, saya sarankan menggunakan 'settings.local.php' sebagai nama file karena cocok dengan pola yang ditetapkan oleh 'settings.default.php'.
Dave Reid

1
Saya telah membuat intisari untuk ini: gist.github.com/1235389 karena saya telah menggunakan ini lebih sering dan lebih sering
chrisjlee

4
Catatan: Drupal 8 sekarang telah menambahkan potongan yang serupa ke file pengaturan secara default, Anda hanya perlu menghapus komentarnya: drupal.org/node/1118520
Berdir

1
@DaveReid: polanya diatur oleh ' default.settings.php ' bukan oleh 'settings.default.php'.
iconoclast

1
Untuk funsies, Anda bisa menggunakan (__DIR__)bukan dirname(__FILE__). Mereka setara .
cdmo

Ini sepertinya Anda menciptakan kembali fungsionalitas multisite bawaan Drupal.

Secara pribadi, saya menyimpan semua tema standar dan modul untuk situs sites/all, dan kemudian memiliki sites/dev.example.comdan sites/example.com.

Sebagai bonus tambahan, Anda kemudian dapat memiliki filesfolder yang berbeda untuk setiap situs, dan Anda juga dapat menambahkan modul pengembangan apa pun sites/dev.example.com/modules.


Itu masuk akal, tapi saya punya beberapa situs di mana sudah ada 5-10 folder multisite, dan memiliki semua tema untuk situs-situs di situs / semua / tema bisa sangat mengganggu. Belum lagi penggunaan custom.module untuk setiap situs. Saya kira saya bisa menggunakan sitename_custom.module sebagai gantinya: - /
geerlingguy

2
Anda selalu dapat mencoba menggunakan tautan simbolis dari sites/dev.example.com/moduleskesites/example.com/modules
Paul Jones

Menerima jawaban ini - saya akan mencoba ini di situs yang sedang saya kerjakan. Sepertinya cocok untuk alur kerja saya.
geerlingguy

9
Saya pikir ini sebenarnya cara yang buruk untuk menangani lingkungan dev dan pementasan karena mereka sebenarnya bukan situs yang berbeda / terpisah, hanya versi berbeda dari situs yang sama. Dalam hal ini Anda sangat ingin menghindari memiliki file terpisah untuk setiap situs. Saya sangat merekomendasikan menggunakan metode yang disebutkan di bawah ini di mana settings.php diversi dan pengaturan khusus untuk setiap situs (pengaturan DB) dimasukkan ke local.settings.php yang tidak diversi.
Mikey P

1
@ Mike P - keduanya solusi valid - saya pikir sebagian besar terserah preferensi pribadi / tim di sini ... ada pengorbanan dengan kedua pendekatan, menurut saya.
geerlingguy

Saya lebih suka mengabaikan file secara lokal (menggunakan .gitignorefile di git) dan kemudian menyimpan versi terpisah jika file pada setiap host.


1
Ini adalah solusi yang menarik, meskipun saya suka melacak setting.php di git (beberapa bug yang saya miliki muncul karena perubahan setting.php ...). Apakah ada cara saya bisa meminta checkout git lokal saya mengganti file itu dengan file saya sendiri (selain meminta saya menyalin file saya sendiri)?
geerlingguy

1
Itu yang saya lakukan juga. File dengan data konfigurasi, terutama dengan kredensial basis data tidak memiliki tempat di VCS.
mmartinov

@geerlingguy ya Anda bisa. Silakan baca pembaruan saya (jika akan dipublikasikan;)
sobi3ch

@martin Saya setuju, tapi jangan lupa kita bisa memiliki repo terpisah KHUSUS hanya untuk file INI! Anda dapat membacanya di pembaruan saya.
sobi3ch

Saya cenderung selalu mengatur entri file DNS atau host dan menggunakan

dev.example.com
staging.example.com

dan

example.com

Kemudian saya memiliki direktori file pengaturan pengaturan yang sepenuhnya terpisah dengan direktori file yang berbeda. Misalnya ./sites/dev.example.com/files


Masalah yang saya lihat dengan pendekatan itu adalah bahwa saya sering memiliki direktori / tema / dan / modul / yang saya gunakan untuk setiap situs (sering dalam pengaturan multisite), dan karena saya perlu menggunakan modul dan tema khusus situs tersebut untuk lokal , dev dan produksi, saya tidak bisa hanya melakukan host / multisite seperti itu: - /
geerlingguy

Poin bagus. Saya kira saya lupa bahwa saya menghubungkan hal-hal itu masuk
Stewart Robinson

Anda dapat membuat symlink dan membagikan folder tema dan modul dengan cara itu. Jadi pada dasarnya folder utama Anda akan menjadi folder produksi dan kemudian darinya Anda dapat membuat symlink ke stage dan dev dan lokal.
gansbrest

Mengapa tidak memiliki beberapa folder berdasarkan nama host pengembangan?

Contoh

  • situs / dev1.domain.com
  • situs / dev2.domain.com
  • situs / dev3.domain.com
  • situs / www.domain.com

Masing-masing dengan file pengaturannya sendiri dan db_url.


Masalah potensial: File yang disimpan / diunggah dalam satu folder situs tidak akan dapat diakses yang lain.
Greg

Lihat balasan saya ke @Stewart :)
geerlingguy

Buat symlink ke folder file pusat
Kevin

Jika satu-satunya hal yang berubah adalah kredensial basis data, maka Anda dapat mengatur variabel lingkungan di konfigurasi host virtual lokal Anda (dan pementasan / produksi) atau dalam .htaccess folder di atas root web Anda. Ini contoh sederhana:

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

Saya kemudian dapat membuat file .htaccess di sini:

/var/www/example.com/.htaccess

yang memiliki kode berikut:

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

Kemudian di /var/www/example.com/drupal-resides-here/sites/default/settings.php(atau apa pun) Anda dapat mengambil kredensial db seperti:

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

Ini memungkinkan banyak pengembang menjalankan berbagai hal secara lokal dan Anda dapat mendorong ke pementasan / produksi sambil tetap melacak settings.php (ada lebih banyak hal di sana daripada hanya kredensial basis data ...). Anda juga tidak perlu melacak beberapa file settings.php.


Saya pribadi berpikir ini adalah cara terbaik untuk pergi. Namun, pengaturan kami, kami menambahkan pernyataan SetEnv ke konfigurasi apache. Buat itu sedikit lebih aman.
Scott Joudry

Itu penggunaan yang menarik untuk .htaccess dan penyimpanan variabel. Tapi bagaimana dengan saat Anda berlari drush up --y? Itu akan menimpa file .htaccess dasar Anda.
Screenack

Ini dilakukan dalam .htaccessfile level di atas webroot. Misalnya, /var/www/.htaccesssimpan arahan ini, dan /var/www/drupal/.htaccessakan menjadi milik Drupal .htaccess. Anda juga bisa memasukkannya ke dalam konfigurasi host virtual Apache, yang bahkan lebih bagus. Terlepas dari semua itu, kami hampir selalu memiliki hal-hal khusus di webroot .htaccessdan oleh karena itu jika kami memperbarui Drupal kami perlu membandingkan .htaccessperubahan dengan Git.
Charlie Schliesser

Solusi paling sederhana dan paling efisien yang hanya satu baris adalah sebagai berikut. Cukup sertakan di baris terakhir file settings.php Anda:

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

Simbol @ di bagian depan berarti tidak menampilkan kesalahan apa pun meskipun tidak menemukan file itu. Setup khas seperti ini melibatkan persyaratan untuk memeriksa apakah file itu ada. Ini menyelesaikannya dalam satu baris tanpa itu.

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

Juga dikenal sebagai operator PHP STFU .


Sederhana, tapi menurut saya paling tidak efisien. seanmonstar.com/post/909029460/…
AyeshK
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.