Settings.php- এর জন্য পরামর্শ - স্থানীয় ডেভ, ডেভলপমেন্ট সার্ভার, লাইভ সার্ভার

80

মূলত, সর্বকালের সর্বশ্রেষ্ঠ একটি প্রশ্ন: আপনি আপনার বিকাশ / স্টেজিং ওয়ার্কফ্লোতে সেটিংস.এফপি ব্যবহার করছেন এমন কয়েকটি উপায় কী?

এই মুহুর্তে আমার সাথে আমার সেটিংস.এফপি ফাইলটি নীচের মত সেট আপ হয়েছে এবং আমি আমার বিকাশটি সার্ভারের O HOST নির্দেশিকা on ভিত্তিতে ভিত্তি করেছিলাম যার অর্থ ডেভেলপমেন্ট (ভাগ করা) সার্ভার, লোকাল.এক্সামেল জন্য আমি dev.example.com এ কাজ করতে পারি। আমার স্থানীয় কম্পিউটারের জন্য কম (এবং অন্যান্য দেবের স্থানীয় কোড চেকআউট), এবং লাইভ সাইটের জন্য www.example.com (বা কেবল উদাহরণ.কম)।

(এই কোডটি সেটিংস.এফপি এর 'ডেটাবেস সেটিংস' বিভাগে রয়েছে):

$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;

}
?>

এটি বেশিরভাগ কাজের জন্য বেশ ভালভাবে কাজ করে তবে এর অর্থ আমাদের প্রচলিত বহিরাগত কোডগুলি আমাদের ভাগ করা সেটিংস.এফপি ফাইলের চারপাশে বসে আছে ... এর থেকে আরও ভাল কোনও উপায় আছে কি?

workflows configuration-management staging

— geerlingguy
সূত্র

আপনি Drupal এর বহু-সাইটে সমাধান ব্যবহার করা উচিত drupal.org/node/290768

— sobi3ch

66

আমি যা করি সেটি সেই ফাইলটিকে একটি সেটিংস.এফপি এবং একটি স্থানীয়.সেটিংস.পিএফ-এ পৃথক করা।

Settings.php এর শেষে নিম্নলিখিত কোডটি রয়েছে:

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

এরপরে স্থানীয় ফাইলটি আপনি যে কোনও ভিসিএস ব্যবহার করছেন তা থেকে বাদ দেওয়া হবে। সুবিধাটি হ'ল আপনি সেটিংস স্থাপন করতে পারেন যা সেটিংস.এফপিএফগুলিতে সমস্ত ক্ষেত্রে সাধারণ এবং সেই সংস্করণটি স্বয়ংক্রিয়ভাবে বিতরণ করা এবং স্থানীয় স্টাফগুলিকে লোকাল.সেটিংস.এফপি রাখতে পারেন in

— Berdir
সূত্র

2

এটি আসলে drupal.org নিজেই ব্যবহৃত কৌশল এবং আমরা প্যালান্টিআরনেটে ধারাবাহিকভাবে ব্যবহার করি। বাইকশেডের জন্য, আমি 'সেটিংস.ডেফল্ট.এফপি' দ্বারা নির্ধারিত প্যাটার্নটির সাথে মিল রেখে ফাইলের নাম হিসাবে 'सेटिंग.local.php' ব্যবহার করার পরামর্শ দিই।

— ডেভ রেড

1

আমি এটার জন্য একটি টুকরো তৈরি করেছি: gist.github.com/1235389 যেহেতু আমি এটিকে আরও বেশি করে ঘন ঘন ব্যবহার করে চলেছি

— ক্রিসজলি

4

: দ্রষ্টব্য: Drupal এর 8 এখন ডিফল্ট ভাবে সেটিংস ফাইল একটি অনুরূপ স্নিপেট যোগ করেনি, আপনি শুধু এটা uncomment প্রয়োজন drupal.org/node/1118520

— Berdir

1

@ ডেভিড: প্যাটার্নটি 'ডিফল্ট.সেটিংস.এফপি' দ্বারা সেট করা হয়েছে ' সেটিংস.ডেফল্ট.এফপি ' দ্বারা নয়।

— আইকনোক্লাস্ট

1

ফানসিগুলির জন্য আপনি এর (__DIR__)পরিবর্তে ব্যবহার করতে পারেন dirname(__FILE__)। তারা সমতুল্য ।

— সিডিএমও

26

দেখে মনে হচ্ছে আপনি দ্রুপালের বিল্ট মাল্টিসাইট কার্যকারিতা পুনরুদ্ধার করছেন।

ব্যক্তিগতভাবে, আমি সাইটের জন্য সব মান থিম এবং মডিউল রাখা sites/all, এবং তারপর আছে sites/dev.example.comএবং sites/example.com।

অতিরিক্ত বোনাস হিসাবে আপনি filesপ্রতিটি সাইটের জন্য আলাদা আলাদা ফোল্ডার রাখতে পারেন এবং আপনি যে কোনও বিকাশ মডিউলও যুক্ত করতে পারেন sites/dev.example.com/modules।

— পল জোন্স
সূত্র

এটি কিছুটা বোধগম্য হয় তবে আমার কয়েকটি সাইট রয়েছে যেখানে ইতিমধ্যে 5-10 মাল্টিসাইট ফোল্ডার রয়েছে এবং সাইটগুলি / সমস্ত / থিমগুলিতে sites সাইটগুলির জন্য সমস্ত থিম থাকা বেশ বিরক্তিকর হতে পারে। প্রতিটি সাইটের জন্য আমার কাস্টম.মডিউলটির সাধারণ ব্যবহারের কথা উল্লেখ করবেন না। / -: আমি পরিবর্তে আমি sitename_custom.module ব্যবহার করতে পারে অনুমান

— geerlingguy

2

আপনি সর্বদা প্রতীকী লিঙ্কগুলি ব্যবহার করতে চেষ্টা করতে sites/dev.example.com/modulesপারেনsites/example.com/modules

— পল জোন্স

এই উত্তরটি স্বীকার করে - আমি বর্তমানে যে সাইটে কাজ করছি তা এই সাইটে চেষ্টা করতে যাচ্ছি। আমার কাজের প্রবাহের জন্য বেশ ভাল লাগছে।

— জেরলিংগুই

9

আমি মনে করি এটি আসলে দেব এবং মঞ্চ পরিবেশকে পরিচালনা করার জন্য একটি দুর্বল উপায় কারণ তারা আসলে পৃথক / পৃথক সাইট নয়, একই সাইটের বিভিন্ন সংস্করণ। এই ক্ষেত্রে আপনি প্রতিটি সাইটের জন্য পৃথক ফাইল থাকা এড়াতে চান। আমি নীচে উল্লিখিত পদ্ধতিটি ব্যবহার করার পরামর্শ দিচ্ছি যেখানে সেটিংস.এফপি সংস্করণযুক্ত এবং প্রতিটি সাইটের জন্য নির্দিষ্ট সেটিংস (ডিবি সেটিংস) কোনও স্থানীয়.সেটিংস.পিপিতে দেওয়া হয় যা সংস্করণযুক্ত নয়।

— মিকি পি

1

@ মাইকি পি - উভয় সমাধানই বৈধ — আমি মনে করি এটি বেশিরভাগ ব্যক্তিগত / দলের পছন্দের উপর নির্ভর করে ... আমার মতে উভয় পদ্ধতির সাথেই ট্রেড অফ রয়েছে।

— geerlingguy

10

আমি স্থানীয়ভাবে ফাইলটি উপেক্ষা করতে পছন্দ করি ( .gitignoreগিটে একটি ফাইল ব্যবহার করে ) এবং তারপরে প্রতিটি হোস্টে ফাইলটি পৃথক সংস্করণ রাখি ।

— ACK
সূত্র

1

এটি একটি আকর্ষণীয় সমাধান, যদিও আমি গিটে সেটিংস.এফপি ট্র্যাকিংয়ের মতো করি (কিছু বাগ আমার ক্রপ হয়ে গেছে সেটিংস.এফপি পরিবর্তনের কারণে ...)। আমি কীভাবে আমার স্থানীয় গিট চেকআউটটি ফাইলটি নিজের সাথে প্রতিস্থাপন করতে পারি (আমার নিজের ফাইলে আমাকে অনুলিপি দেওয়ার পাশাপাশি)?

— geerlingguy

1

আমিও তাই করি। কনফিগারেশন ডেটাযুক্ত ফাইলগুলি, বিশেষত ডাটাবেস শংসাপত্রগুলির সাথে ভিসিএসে কোনও স্থান নেই।

— এমটার্টিনভ

@ জিরলিংগুয়ে হ্যাঁ আপনি পারেন দয়া করে আমার আপডেটটি পড়ুন (এটি প্রকাশিত হলে;)

— sobi3ch

@ মার্টিন আমি সম্মত, তবে আসুন ভুলে যাবেন না যে আমরা কেবলমাত্র এই ফাইলটির জন্য বিশেষ পৃথক রেপো রাখতে পারি! আপনি আমার আপডেটে এটি পড়তে পারেন।

— sobi3ch

7

আমি সর্বদা ডিএনএস বা হোস্ট ফাইল এন্ট্রি এবং ব্যবহার সেট করি tend

dev.example.com
staging.example.com

এবং

example.com

তারপরে আমার কাছে পৃথক পৃথক সেটিংস ফাইল ডিরেক্টরি রয়েছে যার মধ্যে পৃথক পৃথক ফাইল ডিরেক্টরি রয়েছে। উদাহরণস্বরূপ ./sites/dev.example.com/files

— স্টুয়ার্ট রবিনসন
সূত্র

এই পদ্ধতির সাথে আমি যে সমস্যাটি দেখছি তা হ'ল আমার প্রায়শই একটি / থিম / এবং / মডিউল / ডিরেক্টরি থাকে যা আমি প্রতিটি সাইটের জন্য ব্যবহার করি (প্রায়শই একটি মাল্টিসাইট সেটআপে), এবং যেহেতু আমাকে স্থানীয় জন্য সেই সাইট-নির্দিষ্ট মডিউল এবং থিমগুলি ব্যবহার করতে হবে , দেব এবং প্রযোজনা, আমি ঠিক তেমন হোস্ট / মাল্টিসাইট করতে পারি না: - /

— জেরলিংগুই

ভাল যুক্তি. আমার ধারণা আমি এই জিনিসটি সিমিলিং করে ফেলেছি

— স্টিয়ার্ট রবিনসন

আপনি একটি সিমলিংক তৈরি করতে পারেন এবং থিম এবং মডিউলগুলির ফোল্ডারগুলি সেভাবে ভাগ করতে পারেন। সুতরাং মূলত আপনার মূল ফোল্ডারটি একটি উত্পাদন ফোল্ডার হবে এবং তারপরে আপনি পর্যায় এবং দেব এবং স্থানীয় একটি সিমলিংক তৈরি করতে পারেন।

— গ্যানস্রেস্ট 21 '10 এ

5

বিকাশ হোস্টের নামের ভিত্তিতে কয়েকটি ফোল্ডার কেন নেই?

উদাহরণ

সাইট / dev1.domain.com
সাইট / dev2.domain.com
সাইট / dev3.domain.com
সাইট / www.domain.com

প্রত্যেকের নিজস্ব সেটিংস ফাইল এবং db_url রয়েছে।

— কেভিন
সূত্র

সম্ভাব্য সমস্যা: একটি সাইটের ফোল্ডারে সংরক্ষিত / আপলোড করা ফাইলগুলি অন্যটিতে অ্যাক্সেসযোগ্য হবে না।

— গ্রেগ

@ স্টিওয়ার্টে আমার উত্তর দেখুন :)

— জেরলিংগুই

কেন্দ্রীয় ফাইল ফোল্ডারে সিমনলিঙ্কগুলি তৈরি করুন

— কেভিন

2

যদি কেবলমাত্র পরিবর্তনযোগ্য বিষয়গুলি ডাটাবেস শংসাপত্রগুলি হয় তবে আপনি আপনার স্থানীয় (এবং স্টেজিং / প্রোডাকশন) ভার্চুয়াল হোস্ট কনফিগারেশনে বা আপনার ওয়েবের মূলের উপরে একটি ফোল্ডারে একটি .htaccess এ এনভায়রনমেন্ট ভেরিয়েবল সেট করতে পারেন। এখানে একটি সাধারণ উদাহরণ:

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

তারপরে আমি এখানে একটি htaccess ফাইল তৈরি করতে পারি:

/var/www/example.com/.htaccess

যার নিম্নলিখিত কোড রয়েছে:

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

তারপরে /var/www/example.com/drupal-resides-here/sites/default/settings.php(বা যাই হোক না কেন) আপনি ডিবি শংসাপত্রগুলি যেমন ধরতে পারেন:

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

এটি একাধিক বিকাশকারীকে স্থানীয়ভাবে জিনিস চালাতে দেয় এবং সেটিংস.এফপি ট্র্যাক করার সময় আপনি স্টেজিং / উত্পাদনের দিকে ধাক্কা দিতে পারেন (সেখানে কেবলমাত্র ডাটাবেস শংসাপত্রগুলির চেয়ে আরও বেশি কিছু রয়েছে ...)। আপনাকে একাধিক সেটিংস.এফপি ফাইলগুলি ট্র্যাক রাখতে হবে না।

— চার্লি শ্লিয়েসার
সূত্র

আমি ব্যক্তিগতভাবে মনে করি এটিই যাওয়ার সেরা উপায়। যাইহোক, আমাদের সেট আপ আমরা অ্যাপাচি কনফিগারেশনে SetEnv বিবৃতি যুক্ত করি। এটিকে কিছুটা সুরক্ষিত করে তোলে।

— স্কট জৌদ্রি 21

এটি .htaccess এবং ভেরিয়েবল স্টোরেজের জন্য একটি আকর্ষণীয় ব্যবহার। তবে আপনি যখন দৌড়াবেন তখন কী হবে drush up --y? এটি আপনার বেস .htaccess ফাইলটি ওভাররাইট করবে।

— স্ক্রিনাক

এটি .htaccessওয়েবরুটের এক স্তরের উপরে একটি ফাইলে করা হয় । উদাহরণস্বরূপ, /var/www/.htaccessএই নির্দেশাবলী সংরক্ষণ করে এবং /var/www/drupal/.htaccessএটি দ্রুপালের হবে .htaccess। আপনি এটিকে কেবল অ্যাপাচি ভার্চুয়াল হোস্ট কনফিগারেশনে রাখতে পারেন, এটি আরও সুন্দর। এগুলির যে কোনও নির্বিশেষে, আমাদের প্রায়শই ওয়েব্রুটগুলিতে কাস্টম স্টাফ .htaccessথাকে এবং তাই আমরা ড্রুপাল আপডেট করলে আমাদের .htaccessগিটের সাথে পরিবর্তনগুলি তুলনা করতে হবে ।

— চার্লি শ্লিয়েসার

0

সহজ এবং সর্বাধিক দক্ষ সমাধান যা কেবলমাত্র এক লাইনের নীচে রয়েছে। এটি আপনার সেটিংস.এফপি ফাইলের শেষ লাইনে অন্তর্ভুক্ত করুন:

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

সম্মুখের @ প্রতীকটির অর্থ হ'ল কোনও ফাইল ত্রুটি প্রদর্শন করবেন না এমনকি যদি এটি ফাইলটি না খুঁজে পায়। সাধারণ সেটআপ এর মতো ফাইলটি আছে কিনা তা যাচাই করার জন্য শর্তযুক্ত জড়িত। এটি এটি ছাড়াই এক লাইনে এটি সম্পাদন করে।

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

এসটিএফইউ পিএইচপি অপারেটর হিসাবেও পরিচিত ।

— পটোশি パトシ
সূত্র

সহজ, তবে আমি সবচেয়ে কার্যকর বলে মনে করি না। seanmonstar.com/post/909029460/…

— আয়শক