Bagaimana mencegah Devel module dipasang pada lingkungan produksi


26

Dengan menggunakan manajer Konfigurasi Drupal 8 yang baru, bagaimana saya bisa mencegahnya memasang modul Devel pada lingkungan tertentu? Sejauh yang saya tahu, menginstalnya di lokal saya berarti lain kali saya mengekspor konfigurasi dan memindahkannya ke lingkungan saya yang lain (dev, test, prod), itu akan secara otomatis diaktifkan.


Apakah menggunakan drushdapat diterima? Saya tahu beberapa hari yang lalu drush config-export --skip-modules=devel. Mungkin ada yang serupa tanpa menggunakan drush, tapi saya tidak tahu.
mradcliffe

Jadi saya harus melakukan itu setiap kali saya mengekspor konfigurasi? Harus ada cara yang lebih baik: |
cambraca

Mungkin Anda dapat menambahkan beberapa file konfigurasi ke .gitignore Anda.
digitaldonkey


2
Saya pikir pertanyaan ini terlalu luas dalam retrospeksi. Mungkin ada banyak jawaban bagus karena tergantung pada apa proses pembangunan dan pengembangan untuk situs tersebut.
mradcliffe

Jawaban:


18

Metode: Drush

  • Drush dapat mengabaikan status ekstensi yang diaktifkan saat menyinkronkan konfigurasi.

    drush cex --skip-modules=devel

    drush cim --skip-modules=devel

  • Dengan alat Drush CMI Anda dapat beroperasi dengan daftar konfigurasi yang harus diabaikan.

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

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

Metode: Modul

  • Anda dapat menggunakan modul Split Konfigurasi yang memungkinkan Anda untuk:

    1. Pisahkan beberapa konfigurasi ke folder khusus
    2. Konfigurasi daftar hitam
    3. Abaikan serangkaian konfigurasi
    4. Dikonfigurasi oleh entitas konfigurasi
  • Konfigurasi Modul mode hanya baca

    Modul ini memungkinkan untuk mengunci setiap perubahan konfigurasi yang dilakukan melalui UI admin Drupal. Ini dapat berguna dalam skenario di mana misalnya konfigurasi perubahan tidak boleh dilakukan pada lingkungan produksi, tetapi hanya pada lingkungan pementasan atau lokal.

    $settings['config_readonly'] = TRUE;

  • Dan modul lain adalah Lingkungan Config yang memungkinkan Anda untuk mengesampingkan konfigurasi berdasarkan per-lingkungan.


2
Saya benar-benar tidak suka memiliki semua dependensi perpustakaan untuk modul devel pada server produksi saya, jadi saya menambahkannya ke komposer menggunakan composer require --dev drupal/devel. Bonus tambahan adalah pemasangan komposer lebih cepat, membuat prod menyebarkan lebih cepat.
Duncanmoo


6

Pembaruan : Fitur yang dijelaskan di bawah ini baru-baru ini dihapus https://www.drupal.org/project/config_split/issues/2926505


Jika Anda menggunakan drush dalam proses penyebaran Anda, Anda dapat melakukan hal berikut:

Buat drushrc.phpfile di direktori yang sama dengan Anda settings.php(misalnya docroot/sites/default:) dan letakkan yang berikut:

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

Ini berarti, bahwa Anda dapat memanipulasi drush cex/ drush cimperintah untuk melewati modul, selama prosesnya.

Anda dapat membaca lebih lanjut tentang Menggunakan Filter Modul Konfigurasi di Drush 8 .


5

drush cex --skip-modulestelah dihapus karena config_split seperti yang dijelaskan dalam masalah ini sehingga solusi di sini berdasarkan pada drush tidak bekerja untuk saya.

Berikut adalah solusi berdasarkan solusi Duncanmoo menggunakan modul config_exclude

1. Instal config_exclude menggunakan Composer memerlukan --dev dan konfigurasikan

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

izinkan pengaturan.php untuk digunakan pada lingkungan dev lokal Anda

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

Tambahkan pengaturan config_exclude dalam file lokal

$ nano sites/default/setting.local.php

di sini adalah beberapa pengaturan sampel

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

NOTE1: config_filter adalah dependensi config_exclude jadi jika Anda tidak membutuhkannya, Anda dapat mengecualikannya di atas

CATATAN2: Ini settings.local.phpbukan keharusan. Itu tergantung pada apakah dikendalikan oleh VCS Anda atau tidak.

2. Komposer memerlukan --dev

Saat mengaktifkan modul yang murni untuk pengembangan, gunakan flag --dev:

$ composer require --dev drupal/devel

Ini menghasilkan dependensi yang ditambahkan ke file composer.json di bawah keharusan-dev:

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

Jadi, jika Anda menginstal situs TANPA modul dev Anda gunakan:

$ composer install --no-dev

CATATAN: Pada lingkungan pementasan dan produksi Anda, Anda harus selalu melakukan --no-dev

3. gunakan drush cex seperti biasa

$ drush cex 

tidak akan mengekspor pengaturan modul yang dikecualikan

CATATAN: Saya punya diperhatikan core.extension pengaturan tampaknya telah dimodifikasi setelah menjalankan perintah di atas tetapi .yml sesuai tidak pernah ditulis pada hard drive (bahkan setelah mengkonfirmasikan will be deleted and replaced with the active config) sehingga tidak ada yang akan berkomitmen, saya kira itu tergantung pada internal modul config_exclude


Saya memiliki pengalaman yang sangat mirip dengan @GiorgosK mengikuti saran di atas. Solusi ini bekerja dengan sempurna untuk saya dan berisi saran yang dipikirkan dengan baik juga. Saya juga melihat core.extension negatif palsu tapi itu memang TIDAK mengubah status untuk git jadi semuanya baik-baik saja. Terima kasih
vrwired

2

Ada masalah yang menarik untuk Drupal 8.3.x: Izinkan modul pengembangan untuk keluar dari konfigurasi-ekspor . Konsensus umum adalah bahwa Split Konfigurasi saat ini merupakan solusi terbaik.

Komentar oleh swentel :

Hanya ingin mendokumentasikan secara singkat cara config_split bekerja: Entitas config split config mendefinisikan apa yang dimasukkan dalam daftar hitam, memungkinkan Anda untuk membuat daftar hitam modul dan / atau objek konfigurasi. Contoh kanonik, menjadi devel, sudah memiliki use case yang menarik: ia datang dengan system.menu.devel yang, jika Anda blacklist devel, file menu konfigurasi tidak akan dihapus karena tidak ada ketergantungan. Meskipun ini bukan masalah besar, config split memungkinkan Anda memilihnya sendiri sehingga dihapus dari lingkungan.

Komentar oleh geerlingguy :

Saya telah mencoba beberapa metode berbeda dalam mengelola konfigurasi khusus lingkungan, dan config_split tampaknya mencapai kegunaan yang tepat vs keseimbangan overhead tambahan yang terbaik sejauh ini. Ini sederhana dan ringan, tetapi memungkinkan saya untuk menandai (dan terus menggunakan) konfigurasi tertentu hanya di lingkungan tertentu.


2

Split Konfigurasi mungkin merupakan solusi yang layak untuk beberapa orang.

Manajemen konfigurasi Drupal 8 bekerja paling baik ketika mengimpor dan mengekspor seluruh rangkaian konfigurasi situs. Namun, kadang-kadang pengembang suka memilih keluar dari kekokohan CM dan memiliki set super-konfigurasi yang aktif pada mesin pengembangan mereka dan hanya menggunakan subset. Contoh kanonik untuk ini adalah memiliki modul devel diaktifkan atau memiliki beberapa penempatan blok atau tampilan di lingkungan pengembangan dan kemudian tidak mengekspornya ke dalam set konfigurasi yang akan digunakan, namun masih dapat berbagi konfigurasi pengembangan dengan kolega.

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


+1 untuk konfigurasi split, saya selalu menggunakannya untuk membuat Devel dan modul lain seperti Field UI dan Views UI dinonaktifkan di prod. Lihat Menonaktifkan modul menggunakan konfigurasi config .
leymannx

2

Ada cara yang rapi untuk melakukan hal ini, di mana Anda berakhir dengan modul dev Anda yang dibuat di komposer untuk kenyamanan dan konfigurasi modul-modul itu tidak ditambahkan ke ekspor konfigurasi Anda (ada 2 bagian):

1. Komposer memerlukan --dev Ketika mengaktifkan modul yang murni untuk pengembangan kemudian gunakan flag --dev:

$ composer require --dev drupal/devel

Ini menghasilkan dependensi yang ditambahkan ke file composer.json di bawah keharusan-dev:

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

Jadi, jika Anda menginstal situs TANPA modul dev Anda, Anda mengatakan:

$ composer install --no-dev

NB: Tentang lingkungan pementasan dan produksi Anda, Anda harus selalu melakukan --no-dev

2. Gunakan modul config_split

Modul pemisahan konfigurasi memungkinkan Anda membuat pengelompokan ekspor konfigurasi yang dapat diaktifkan atau dinonaktifkan di lingkungan.

Saya sebenarnya memiliki 3 split:

  1. Konfigurasi situs utama (diaktifkan di mana-mana; dev dan pementasan dan produksi)
  2. Konfigurasi pementasan (diaktifkan di dev dan pementasan) - termasuk modul reroute email
  3. Konfigurasi conf - termasuk devel, kint ... tetapi tidak mengubah rute email yang datang dengan konfigurasi pementasan diaktifkan di dev.

1
Anda benar-benar tidak boleh menggunakan dependensi dev dengan cara ini. Mereka lebih untuk alat, seperti sniffer kode, yang Anda tidak perlu berjalan dalam produksi. Jika mereka diaktifkan dan Drupal mengharapkan modul untuk diinstal dan kode tidak ada maka ini dapat menyebabkan ketidakstabilan situs. Drupal / Komposer mungkin masih berusaha memuat file yang tidak ada di sistem file jika itu adalah ketergantungan dev.
Frank Robert Anderson

@ FrankRobertAnderson Anda tidak mengusulkan solusi yang lebih baik? Saya tidak ingin mengembangkan modul atau pustaka tergantung pada server produksi saya, apa yang Anda usulkan?
Duncanmoo

Drupal tidak benar-benar memberikan opsi yang baik untuk ini. Rencana Anda tidak mengerikan, tetapi akan menimbulkan masalah jika Anda tidak berhati-hati. Masalah yang saya miliki dengan rencana Anda adalah config_split menjadi pin yang bergantung pada seluruh situs Anda. Saya akan memilih Anda jika bukan karena hal ketergantungan dev, yang bahkan bukan pertanyaan di OP.
Frank Robert Anderson

1

Saya membuat skrip kecil untuk melakukan semuanya dalam satu kesempatan.

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

1

Anda juga dapat melihat modul Config Ignore .

Modul ini adalah alat untuk membiarkan Anda menjaga konfigurasi yang Anda inginkan.

Katakanlah Anda menginginkan konfigurasi system.site (yang berisi nama situs, slogan, email, dll) agar tidak tersentuh, di situs langsung Anda, apa pun konfigurasinya, dalam folder ekspor mengatakan.

Atau mungkin Anda mulai bosan dengan devel. Pengaturan berubah setiap kali Anda mengimpor konfigurasi?


Modul Config Ignore tidak cocok dalam kasus ini. Dari halaman modul: Jangan abaikan konfigurasi core.extension karena akan mencegah Anda mengaktifkan modul baru dengan impor konfigurasi. Gunakan modul Config Split untuk modul khusus lingkungan.
bmunslow

1

Anda dapat menggunakan modul override penyebaran untuk ini. Baca tautan berikut untuk penjelasan terperinci:

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

Namun , Cara terbaik untuk melakukan ini adalah dengan menonaktifkan modul Anda di lokal dan kemudian mengekspor konfigurasi.

Drupal menyediakan cara untuk mengesampingkan pengaturan konfigurasi settings.php, tetapi tidak valid untuk menonaktifkan / mengaktifkan modul.

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