उत्पादन वातावरण पर डेवेल मॉड्यूल को कैसे रोका जाए

Question

नए Drupal 8 कॉन्फ़िगरेशन प्रबंधक का उपयोग करके, मैं इसे कुछ निश्चित वातावरणों पर Devel मॉड्यूल को स्थापित करने से कैसे रोक सकता हूं? जहां तक ​​मुझे पता है, इसे अपने स्थानीय पर स्थापित करने का मतलब है अगली बार जब मैं कॉन्फ़िगरेशन को निर्यात करता हूं और इसे अपने अन्य वातावरणों (देव, परीक्षण, ठेस) में स्थानांतरित करता हूं, तो यह स्वचालित रूप से सक्षम हो जाएगा।

Comments

drushस्वीकार्य उपयोग कर रहा है? मुझे दूसरे दिन के बारे में पता चला drush config-export --skip-modules=devel। ड्रश का उपयोग किए बिना कुछ समान हो सकता है, लेकिन मुझे नहीं पता।

— mradcliffe

इसलिए मुझे यह करना होगा कि हर बार मैं कॉन्फिगरेशन को एक्सपोर्ट करूं? एक बेहतर तरीका है: |

— ०६ पर cambraca

हो सकता है कि आप अपने .gitignore में कुछ config फाइल जोड़ सकते हैं।

— digitaldonkey

यह संबंधित है: drupal.stackexchange.com/questions/185536/…

— लेस लिम

मुझे लगता है कि यह प्रश्न पूर्वव्यापी में बहुत व्यापक है। संभवतः कई अच्छे उत्तर हैं क्योंकि यह इस बात पर निर्भर करता है कि साइट के लिए निर्माण और विकास प्रक्रिया क्या है।

— mradcliffe

Answer 1

विधि: Drush

• कॉन्फ़िगरेशन को सिंक्रनाइज़ करते समय Drush एक्सटेंशन की सक्षम स्थिति को अनदेखा कर सकता है।

  drush cex --skip-modules=devel

  drush cim --skip-modules=devel

• साथ Drush CMI उपकरण पर ध्यान नहीं देना विन्यास की सूची के साथ काम कर सकते हैं।

  drush cexy --ignore-list=/path/to/config-ignore.yml

  drush cimy --delete-list=/path/to/config-ignore.yml

विधि: मॉड्यूल

• आप कॉन्फ़िगरेशन स्प्लिट मॉड्यूल का उपयोग कर सकते हैं जो आपको इसकी अनुमति देता है:

  1. समर्पित फ़ोल्डर में कुछ कॉन्फ़िगरेशन को विभाजित करें
  2. ब्लैकलिस्ट कॉन्फ़िगरेशन
  3. कॉन्फ़िगरेशन के एक सेट को अनदेखा करें
  4. कॉन्फ़िगरेशन संस्थाओं द्वारा कॉन्फ़िगर किया गया

• कॉन्फ़िगरेशन केवल-पढ़ने के लिए मोड मॉड्यूल

  यह मॉड्यूल Drupal व्यवस्थापक UI के माध्यम से किए गए किसी भी कॉन्फ़िगरेशन परिवर्तन को लॉक करने की अनुमति देता है। यह उन परिदृश्यों में उपयोगी हो सकता है जहां उदाहरण के लिए कॉन्फ़िगरेशन परिवर्तन उत्पादन वातावरण पर नहीं किया जाना चाहिए, लेकिन केवल मंचन या स्थानीय वातावरण पर।

  $settings['config_readonly'] = TRUE;

• और एक अन्य मॉड्यूल पर्यावरण कॉन्फ़िगरेशन है जो आपको प्रति-पर्यावरण के आधार पर कॉन्फ़िगरेशन को ओवरराइड करने की अनुमति देता है।

Comments

मैं वास्तव में अपने उत्पादन सर्वर पर डेवेल मॉड्यूल के लिए सभी पुस्तकालय निर्भरताएं पसंद नहीं करता हूं, इसलिए मैं इसे संगीतकार का उपयोग करके जोड़ता हूं composer require --dev drupal/devel। जोड़ा गया बोनस यह है कि कंपोज़र इंस्टालेशन तेज़ है, जिससे ठेस तेजी से परिनियोजित होती है।

— डंकनमो

drush cex --skip-मॉड्यूल config_split के पक्ष में हटा दिया गया था ।

— लेमनक्स

Answer 2

अद्यतन : नीचे वर्णित सुविधा हाल ही में हटा दी गई थी https://www.drupal.org/project/config_split/issues/2926505

---

यदि आप अपनी तैनाती प्रक्रिया में ड्रश का उपयोग कर रहे हैं, तो आप निम्न कार्य कर सकते हैं:

drushrc.phpअपनी settings.php(उदाहरण के लिए docroot/sites/default) जैसी निर्देशिका में एक फ़ाइल बनाएँ और निम्नलिखित डालें:

$drush_ignore_modules = array(
  'devel',
  'webprofiler',
  'devel_generate',
  'kint',
  'yaml_editor',
);

$command_specific['config-export']['skip-modules'] = $drush_ignore_modules;
$command_specific['config-import']['skip-modules'] = $drush_ignore_modules;

इसका मतलब है, कि आप मॉड्यूल drush cex/ drush cimप्रक्रिया को छोड़ने के लिए उनकी प्रक्रिया के दौरान हेरफेर कर सकते हैं।

आप ड्रश 8 में कॉन्फ़िगरेशन मॉड्यूल फ़िल्टर का उपयोग करने के बारे में अधिक पढ़ सकते हैं ।

Answer 3

drush cex --skip-modulesइस मुद्दे में बताए अनुसार config_split के पक्ष में हटा दिया गया था, इस प्रकार ड्रश पर आधारित समाधान मेरे लिए काम नहीं किया है।

यहाँ config_exclude मॉड्यूल का उपयोग करते हुए डंकन्यू समाधान पर आधारित समाधान है

1. संगीतकार की आवश्यकता का उपयोग करके config_exclude स्थापित करें --देव और इसे कॉन्फ़िगर करें

$ composer require --dev drupal/config_exclude
$ drush en config_exclude -y
$ nano sites/default/setting.php

अपने स्थानीय देव वातावरण पर सेटिंग्स .php का उपयोग करने की अनुमति दें

if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
  include $app_root . '/' . $site_path . '/settings.local.php';
}

स्थानीय फ़ाइल में config_exclude सेटिंग्स जोड़ें

$ nano sites/default/setting.local.php

यहाँ कुछ नमूना सेटिंग्स है

$settings['config_exclude_modules'] = [
    'devel', 
    'config_exclude',
    'config_filter',
    ...
    'stage_file_proxy',
];

NOTE1: config_filter एक config_exclude निर्भरता है, इसलिए यदि आपको इसके उत्पादन की आवश्यकता नहीं है, तो आप इसे ऊपर छोड़ सकते हैं

टिप्पणी 2:settings.local.php एक आवश्यकता नहीं है। यह इस पर निर्भर करता है कि आपके VCS द्वारा नियंत्रित किया जाता है या नहीं।

2. संगीतकार की आवश्यकता है --देव

जब एक मॉड्यूल को सक्षम करना जो विशुद्ध रूप से विकास के लिए है तो --देव ध्वज का उपयोग करें:

$ composer require --dev drupal/devel

यह उन निर्भरता में परिणाम देता है जिन्हें आवश्यकता-देव के तहत कंपोज़र.जसन फ़ाइल में जोड़ा जा रहा है:

...
    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"
    }
}

यदि आप अपने देव मॉड्यूल के बिना साइट को स्थापित करते हैं तो आप उपयोग करते हैं:

$ composer install --no-dev

नोट: आपके मंचन और ठेस के वातावरण पर आपको हमेशा करना चाहिए - कोई देव

3. जैसा कि आप सामान्य रूप से उपयोग करते हैं, ड्रंक सीएक्स का उपयोग करें

$ drush cex 

बहिष्कृत मॉड्यूल सेटिंग्स में से किसी को निर्यात नहीं करेगा

ध्यान दें: मैंने देखा है कि कोर. टेक्स्ट सेटिंग्स को ऊपर कमांड चलाने के बाद संशोधित किया गया है, लेकिन संबंधित .yml को कभी हार्ड ड्राइव पर नहीं लिखा जाता है (पुष्टि करने के बाद भी will be deleted and replaced with the active config) इसलिए इसमें कुछ भी शामिल नहीं है, मुझे लगता है कि यह निर्भर करता है config_exclude मॉड्यूल के आंतरिक

Comments

ऊपर दिए गए सुझावों के बाद मुझे @GiorgosK जैसा ही अनुभव हुआ। इस समाधान ने मेरे लिए पूरी तरह से काम किया और अच्छी तरह से सलाह के रूप में अच्छी तरह से सोचा था। मैंने भी देखा है कि कोर.स्टेंशन झूठे नकारात्मक हैं लेकिन यह वास्तव में git के लिए स्थिति नहीं बदलता है इसलिए सब ठीक है। धन्यवाद

— vrwired

Answer 4

Drupal 8.3.x के लिए एक दिलचस्प मुद्दा है: विकास मॉड्यूल को कॉन्फ़िगरेशन-निर्यात से बाहर निकलने की अनुमति दें । सामान्य सहमति यह है कि कॉन्फ़िगरेशन स्प्लिट वर्तमान में सबसे अच्छा समाधान है।

स्वेंटेल द्वारा टिप्पणी :

बस संक्षिप्त रूप से दस्तावेज़ करना चाहता था कि config_split कैसे काम करता है: config विभाजन विन्यास इकाई परिभाषित करता है कि क्या ब्लैकलिस्ट किया गया है, जिससे आप मॉड्यूल और / या ऑब्जेक्ट को ब्लैकलिस्ट कर सकते हैं। विहित उदाहरण, देवल होने के नाते, पहले से ही एक दिलचस्प उपयोग का मामला है: यह system.menu.devel के साथ आता है, जो आपके द्वारा हटाए जाने की स्थिति में, मेनू कॉन्फ़िग फ़ाइल को हटाया नहीं जाएगा क्योंकि कोई निर्भरता नहीं है। हालांकि यह एक बड़ी समस्या नहीं है, लेकिन विन्यास विभाजन आपको व्यक्तिगत रूप से चयन करने की अनुमति देता है और साथ ही साथ यह पर्यावरण पर हटा दिया जाता है।

Geerlingguy द्वारा टिप्पणी :

मैंने पर्यावरण-विशिष्ट विन्यास को प्रबंधित करने के कुछ अलग तरीकों की कोशिश की है, और config_split सही प्रयोज्य बनाम अतिरिक्त ओवरहेड संतुलन को अब तक का सबसे अच्छा हिट लगता है। यह सरल और हल्का है, लेकिन मुझे केवल कुछ वातावरणों में निश्चित कॉन्फ़िगरेशन को चिह्नित करने (और उपयोग करना जारी रखने) की अनुमति देता है।

Answer 5

कॉन्फ़िगरेशन स्प्लिट कुछ के लिए एक व्यवहार्य समाधान हो सकता है।

Drupal 8 कॉन्फ़िगरेशन प्रबंधन साइट कॉन्फ़िगरेशन के पूरे सेट को आयात और निर्यात करते समय सबसे अच्छा काम करता है। हालांकि, कभी-कभी डेवलपर्स सीएम की मजबूती से बाहर निकलना पसंद करते हैं और उनके विकास मशीन पर सक्रिय कॉन्फ़िगरेशन का एक सुपर-सेट होता है और केवल एक सबसेट तैनात करता है। इसके लिए विहित उदाहरण है कि विकास नेटवर्क में कुछ ब्लॉक प्लेसमेंट या दृश्य सक्षम होने या फिर उन्हें तैनात करने के लिए कॉन्फ़िगरेशन के सेट में निर्यात नहीं करना है, फिर भी सहकर्मियों के साथ विकास कॉन्फ़िगरेशन को साझा करने में सक्षम है।

https://www.drupal.org/project/config_split

Comments

कॉन्फ़िगर विभाजन के लिए +1, मैं हमेशा उपयोग करता हूं कि डेवेल और अन्य मॉड्यूल जैसे कि फील्ड यूआई और व्यू यूआई को ठेस में अक्षम किया जाए। कॉन्फ़िगर विभाजन का उपयोग करके मॉड्यूल को अक्षम करें देखें ।

— लीमैनक्स

Answer 6

ऐसा करने का एक साफ तरीका है, जहां आप अपने देव मॉड्यूल के साथ सुविधा के लिए कंपोजर में काम करते हैं और उन मॉड्यूल का कॉन्फिगरेशन आपके कॉन्फिगर एक्सपोर्ट में नहीं जोड़ा जाता है (2 भाग हैं):

1. संगीतकार की आवश्यकता होती है --देव जब एक मॉड्यूल को सक्षम करना जो विशुद्ध रूप से विकास के लिए है तो --देव ध्वज का उपयोग करें:

$ composer require --dev drupal/devel

यह उन निर्भरता में परिणाम देता है जिन्हें आवश्यकता-देव के तहत कंपोज़र.जसन फ़ाइल में जोड़ा जा रहा है:

...
    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"
    }
}

यदि आप अपने देव मॉड्यूल के बिना साइट को स्थापित करते हैं तो आप कहते हैं:

$ composer install --no-dev

नायब: आपके मंचन और ठेस वाले वातावरण पर आपको हमेशा करना चाहिए -नो-देव

2. config_split मॉड्यूल का उपयोग करें

कॉन्फ़िगरेशन विभाजन मॉड्यूल आपको कॉन्फ़िगरेशन निर्यात के समूह बनाने की अनुमति देता है जो पर्यावरण में सक्षम या अक्षम हो सकते हैं।

मेरे पास वास्तव में 3 विभाजन हैं:

1. मुख्य साइट विन्यास (हर जगह सक्षम; देव और मंचन और उत्पादन)
2. स्टेजिंग कॉन्फिग (देव और स्टेजिंग में सक्षम) - इसमें राउटर ईमेल मॉड्यूल शामिल है
3. देव कॉन्फिग - इसमें डेवेल, किंट भी शामिल है ... लेकिन रीरूट ईमेल नहीं, क्योंकि यह देव में स्टैगिंग कॉन्फिगर सक्षम होने के साथ आता है।

Comments

आपको वास्तव में इस तरह से देव निर्भरता का उपयोग नहीं करना चाहिए। वे कोड स्निफर जैसे उपकरणों के लिए अधिक हैं, जिन्हें आपको उत्पादन में चलाने की आवश्यकता नहीं होगी। यदि वे सक्षम हैं और Drupal मॉड्यूल को स्थापित करने की उम्मीद कर रहा है और कोड नहीं है तो इससे साइट की अस्थिरता हो सकती है। Drupal / Composer अभी भी एक फ़ाइल को लोड करने का प्रयास कर सकता है जो फ़ाइल सिस्टम पर नहीं है यदि यह एक देवता निर्भरता है।

— फ्रैंक रॉबर्ट एंडरसन

@FrankRobertAnderson आप किसी भी बेहतर समाधान का प्रस्ताव नहीं करते हैं? मैं अपने उत्पादन सर्वर पर डेवेल मॉड्यूल या आश्रित पुस्तकालयों को नहीं चाहता, आप क्या प्रस्ताव करते हैं?

— डंकनमो

Drupal वास्तव में इसके लिए एक अच्छा विकल्प प्रदान नहीं करता है। आपकी योजना भयानक नहीं है, लेकिन अगर आप सावधान नहीं हैं तो यह मुद्दों को जन्म देगा। आपकी योजना के साथ मेरे पास जो समस्या है वह config_split पिन है जो आपकी पूरी साइट पर फिर टिका है। अगर आप देव निर्भरता की चीज़ के लिए नहीं, जो ओपी में एक सवाल भी नहीं था, तो मैं आपको अपना वोट दूंगा।

— फ्रैंक रॉबर्ट एंडरसन

Answer 7

मैंने एक शॉट में यह सब करने के लिए एक छोटी सी स्क्रिप्ट बनाई।

#!/bin/bash

drush pm-uninstall devel -y
drush pm-uninstall field_ui -y
drush pm-uninstall field_name_prefix_remove -y

drush config-export

drush en devel -y
drush en field_ui -y
drush en field_name_prefix_remove -y

Answer 8

आप कॉन्फ़िग इग्नोर मॉड्यूल भी देख सकते हैं ।

यह मॉड्यूल एक ऐसा उपकरण है जिससे आप अपने इच्छित कॉन्फ़िगरेशन को रख सकते हैं।

कहते हैं कि आप ऐसा करते हैं कि आप सिस्टम.साइट कॉन्फिगरेशन (जिसमें उस साइट का नाम, स्लोगन, ईमेल इत्यादि शामिल हैं) को अछूते रहने के लिए, आपकी लाइव साइट पर, कोई फर्क नहीं पड़ता कि एक्सपोर्ट फोल्डर में क्या है।

या हो सकता है कि आप हर बार जब आप कॉन्फ़िगरेशन आयात करते हैं, तो devel.settings बदल जाने से आप थक गए हैं।

Comments

इस मामले में कॉन्फ़िगरेशन इग्नोर मॉड्यूल उपयुक्त नहीं है। मॉड्यूल पृष्ठ से: core.extension कॉन्फ़िगरेशन को अनदेखा न करें क्योंकि यह आपको नए मॉड्यूल को कॉन्फ़िगर करने में सक्षम करेगा आयात कॉन्फ़िगरेशन के साथ। पर्यावरण विशिष्ट मॉड्यूल के लिए कॉन्फ़िगर स्प्लिट मॉड्यूल का उपयोग करें।

— bmunslow

Answer 9

आप इसके लिए परिनियोजन ओवरराइड मॉड्यूल का उपयोग कर सकते हैं। विस्तृत विवरण के लिए निम्नलिखित लिंक पढ़ें:

http://dcycleproject.org/blog/46/continuous-deployment-drupal-style

हालाँकि , ऐसा करने का सबसे अच्छा तरीका यह होगा कि आप अपने मॉड्यूल को लोकल पर डिसेबल कर दें और फिर कॉन्फ़िगरेशन को एक्सपोर्ट करें।

Drupal कॉन्फ़िगरेशन सेटिंग्स को ओवरराइड करने का एक तरीका प्रदान करता है settings.php, लेकिन वे मॉड्यूल को अक्षम / सक्षम करने के लिए मान्य नहीं हैं।

से default.settings.php:

/**
 * Configuration overrides.
 *  * To globally override specific configuration values for this site,
 * set them here. 
 * 
 *
 * blah..blah...blah
 *
 *  
 * There are particular configuration values that are risky to override. For
 * example, overriding the list of installed modules in 'core.extension' is not
 * supported as module install or uninstall has not occurred. Other examples
 * include field storage configuration, because it has effects on database
 * structure, and 'core.menu.static_menu_link_overrides' since this is cached in
 * a way that is not config override aware. Also, note that changing
 * configuration values in settings.php will not fire any of the configuration
 * change events.
 */