วิธีการป้องกันไม่ให้โมดูล Devel ติดตั้งในสภาพแวดล้อมการผลิต

การใช้ตัวจัดการการกำหนดค่า Drupal 8 ใหม่ฉันจะป้องกันไม่ให้ติดตั้งโมดูล Devel ในสภาพแวดล้อมบางอย่างได้อย่างไร เท่าที่ฉันรู้การติดตั้งในเครื่องของฉันหมายถึงครั้งต่อไปที่ฉันส่งออกการกำหนดค่าและย้ายไปยังสภาพแวดล้อมอื่น ๆ ของฉัน (dev, test, prod) มันจะถูกเปิดใช้งานโดยอัตโนมัติ

วิธีการ: 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. กำหนดค่าโดยเอนทิตีการกำหนดค่า

• การกำหนดค่าโมดูลโหมดอ่านอย่างเดียว

  โมดูลนี้อนุญาตให้ล็อคการเปลี่ยนแปลงการกำหนดค่าใด ๆ ที่ทำผ่าน UI ของผู้ดูแลระบบ Drupal สิ่งนี้มีประโยชน์ในสถานการณ์ที่ไม่ควรทำตัวอย่างการเปลี่ยนแปลงการกำหนดค่าในสภาพแวดล้อมการผลิต แต่เฉพาะกับสภาพแวดล้อมแบบ Staging หรือ Local

  $settings['config_readonly'] = TRUE;

• และโมดูลอื่นคือการกำหนดค่าสภาพแวดล้อมที่ช่วยให้คุณสามารถแทนที่การกำหนดค่าบนพื้นฐานต่อสภาพแวดล้อม

อัปเดต : คุณลักษณะที่อธิบายด้านล่างถูกลบออกเมื่อเร็ว ๆ นี้ https://www.drupal.org/project/config_split/issues/2926505

หากคุณกำลังใช้ drush ในกระบวนการปรับใช้ของคุณคุณสามารถทำสิ่งต่อไปนี้:

สร้าง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คำสั่งเพื่อข้ามโมดูลในระหว่างกระบวนการของพวกเขา

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับการใช้ตัวกรองการกำหนดค่าโมดูลใน Drush 8

drush cex --skip-modulesถูกเอาออกไปด้วยความโปรดปรานของ config_split ตามที่อธิบายไว้ในปัญหานี้ดังนั้นการแก้ปัญหาโดยใช้ drush จึงไม่ได้ผลสำหรับฉัน

นี่คือโซลูชันที่อ้างอิงตามโซลูชันDuncanmooโดยใช้โมดูลconfig_exclude

1. ติดตั้ง config_exclude โดยใช้ Composer ต้องการ --dev และกำหนดค่า

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

อนุญาตให้ settings.php ที่จะใช้ในสภาพแวดล้อม dev ท้องถิ่นของคุณ

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 ดังนั้นหากคุณไม่ต้องการการผลิตคุณสามารถยกเว้นได้ด้านบน

NOTE2: สิ่งsettings.local.phpนี้ไม่ใช่ข้อกำหนด ขึ้นอยู่กับว่า VCS ของคุณถูกควบคุมหรือไม่

2. นักแต่งเพลงต้องการ --dev

เมื่อเปิดใช้งานโมดูลที่ใช้สำหรับการพัฒนาอย่างแท้จริงให้ใช้แฟล็ก --dev:

$ composer require --dev drupal/devel

สิ่งนี้ส่งผลให้การพึ่งพาเหล่านั้นถูกเพิ่มเข้าไปในไฟล์ composer.json ภายใต้ require-dev:

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

ดังนั้นหากคุณติดตั้งเว็บไซต์โดยไม่ต้องใช้โมดูล dev ของคุณ:

$ composer install --no-dev

หมายเหตุ:ในสภาพแวดล้อมการจัดเตรียมและการผลิตของคุณคุณไม่ควรทำ - เสมอ

3. ใช้ drush cex ตามปกติคุณใช้

$ drush cex 

จะไม่ส่งออกการตั้งค่าโมดูลที่ยกเว้นใด ๆ

หมายเหตุ:ฉันได้สังเกตเห็นcore.extensionการตั้งค่าปรากฏว่าได้รับการแก้ไขหลังจากใช้คำสั่งดังกล่าว แต่ .yml ที่สอดคล้องกันคือไม่เคยเขียนไว้ในฮาร์ดไดรฟ์ (แม้หลังจากที่ยืนยันwill be deleted and replaced with the active config) เพื่อให้มีอะไรที่จะต้องมุ่งมั่นที่ผมคิดว่ามันขึ้นอยู่กับ ภายในของโมดูลconfig_exclude

มีปัญหาที่น่าสนใจสำหรับ Drupal เป็น 8.3.x: อนุญาตให้โมดูลการพัฒนาจะเลือกออกจากการตั้งค่าการส่งออก ข้อสรุปทั่วไปคือการแบ่งการกำหนดค่าปัจจุบันเป็นทางออกที่ดีที่สุด

ความคิดเห็นโดยswentel :

เพิ่งต้องการเอกสารสั้น ๆ ว่าการทำงานของ config_split: หน่วยงานแยกการกำหนดค่ากำหนดสิ่งที่อยู่ในบัญชีดำช่วยให้คุณสามารถบัญชีดำโมดูลและ / หรือวัตถุการกำหนดค่า ตัวอย่างที่ยอมรับในฐานะ devel มีกรณีการใช้งานที่น่าสนใจอยู่แล้ว: มันมาพร้อมกับ system.menu.devel ซึ่งในกรณีที่คุณขึ้นบัญชีดำ devel ไฟล์ config ของเมนูจะไม่ถูกลบเนื่องจากไม่มีการพึ่งพา แม้ว่าจะไม่ใช่ปัญหาใหญ่ แต่ตัวแยกการตั้งค่าจะช่วยให้คุณสามารถเลือกได้เช่นกัน

ความคิดเห็นโดยgeerlingguy :

ฉันได้ลองใช้วิธีการที่แตกต่างกันสองสามวิธีในการจัดการการตั้งค่าเฉพาะสภาพแวดล้อมและ config_split ดูเหมือนว่าจะใช้งานได้อย่างถูกต้องเมื่อเทียบกับยอดค่าใช้จ่ายพิเศษจนถึงตอนนี้ มันเรียบง่ายและมีน้ำหนักเบา แต่อนุญาตให้ฉันทำเครื่องหมาย (และใช้งานต่อไป) การกำหนดค่าบางอย่างเฉพาะในบางสภาพแวดล้อม

การแยกการกำหนดค่าอาจเป็นโซลูชันที่ทำงานได้สำหรับบางคน

การจัดการการกำหนดค่า Drupal 8 ทำงานได้ดีที่สุดเมื่อนำเข้าและส่งออกการกำหนดค่าไซต์ทั้งชุด อย่างไรก็ตามนักพัฒนาบางครั้งต้องการยกเลิกความแข็งแกร่งของ CM และมีการกำหนดค่า super-set ที่ใช้งานบนเครื่องพัฒนาและปรับใช้ชุดย่อยเท่านั้น ตัวอย่างที่ยอมรับได้สำหรับเรื่องนี้คือการเปิดใช้งานโมดูล devel หรือมีตำแหน่งบล็อกหรือมุมมองบางส่วนในสภาพแวดล้อมการพัฒนาและไม่ส่งออกไปยังชุดการกำหนดค่าที่จะนำไปใช้ แต่ยังคงสามารถแชร์การกำหนดค่าการพัฒนากับเพื่อนร่วมงานได้

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

มีวิธีที่เป็นระเบียบเรียบร้อยในการทำเช่นนี้เมื่อคุณจบลงด้วยโมดูล dev ของคุณที่คอมมิชชันผู้แต่งเพื่อความสะดวกและโมดูลของโมดูลเหล่านั้นจะไม่ถูกเพิ่มในการเอ็กซ์พอร์ต config ของคุณ

1. Composer ต้องการ --dev เมื่อเปิดใช้งานโมดูลที่ใช้สำหรับการพัฒนาอย่างแท้จริงให้ใช้แฟล็ก --dev:

$ composer require --dev drupal/devel

สิ่งนี้ส่งผลให้การพึ่งพาเหล่านั้นถูกเพิ่มเข้าไปในไฟล์ composer.json ภายใต้ require-dev:

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

ดังนั้นหากคุณติดตั้งเว็บไซต์โดยไม่ต้องโมดูล dev ของคุณคุณพูดว่า:

$ composer install --no-dev

หมายเหตุ:ในสภาพแวดล้อมการจัดเตรียมและการผลิตของคุณคุณไม่ควรทำ - เสมอ

2. ใช้โมดูลconfig_split

โมดูลแยกการกำหนดค่าช่วยให้คุณสามารถสร้างกลุ่มของการส่งออกการกำหนดค่าซึ่งสามารถเปิดใช้งานหรือปิดการใช้งานในสภาพแวดล้อม

จริง ๆ แล้วฉันมี 3 แยก:

1. การกำหนดค่าไซต์หลัก (เปิดใช้งานได้ทุกที่ dev และการจัดเตรียมและการผลิต)
2. Staging config (เปิดใช้งานใน dev และ staging) - รวมโมดูล reroute อีเมล
3. Dev config - รวมถึง devel, kint ... แต่ไม่ใช่การเปลี่ยนเส้นทางอีเมลที่มาพร้อมกับการเปิดใช้งานการกำหนดค่า staging ใน dev

ฉันทำสคริปต์เล็ก ๆ เพื่อทำทุกอย่างในนัดเดียว

#!/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

คุณยังสามารถดูโมดูลกำหนดค่าการละเว้น

โมดูลนี้เป็นเครื่องมือที่ช่วยให้คุณสามารถกำหนดค่าที่คุณต้องการ

ให้บอกว่าคุณต้องการกำหนดค่า system.site (ซึ่งมีชื่อไซต์สโลแกนอีเมล ฯลฯ ) เพื่อคงอยู่บนเว็บไซต์สดของคุณไม่ว่าการกำหนดค่าในโฟลเดอร์ส่งออกจะพูดว่า

หรือบางทีคุณอาจรู้สึกเบื่อที่จะต้องเปลี่ยนการตั้งค่า devel ทุกครั้งที่คุณนำเข้าการกำหนดค่า

คุณสามารถใช้โมดูลการแทนที่การปรับใช้สำหรับสิ่งนี้ อ่านลิงค์ต่อไปนี้สำหรับคำอธิบายโดยละเอียด:

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.
 */