Puncte:0

Utilizarea corectă a config_split

drapel cn

Încerc să folosesc config_split, astfel încât să putem ignora/dezactiva unele module/configurații din mediile noastre de dezvoltare și nu vrem ca acestea să fie transferate în mediile noastre de producție.

Cred că am configurat greșit lucrurile, deoarece de fiecare dată când fac modificări de configurare pe dev-ul meu și trec lucrurile în producție și import, suprascrie setările de producție pentru modulele pe care le ignorăm în config_split. (De exemplu, dacă fac o modificare locală a vizualizărilor și export configurația). Când import acea modificare a configurației în prod, dezactivează și modulele (și elimină setările pe care le-am furnizat) pe care le avem în producție și care nu sunt în mediile de dezvoltare.

De exemplu, avem Drupal Shield și Drupal Password Policy setate în producție, dar nu vrem să le setăm în dezvoltare. Avem modulul „shield” și „password_policy” selectat în diviziunea de configurare „dev” pe care am făcut-o, precum și modulele comune „devel” și „admin_toolbar_extras” etc.

Acum, pentru că le ignorăm, ignoră setările noastre în mediile de dezvoltare (dacă este dezactivată pe dezvoltatorul nostru local, rămâne dezactivată după import, invers), dar odată ce trecem la configurația de producție și import, încearcă să dezactiveze scutul și password_policy în producție și modificați toate setările noastre personalizate pe care le-am setat pentru aceasta.

Trebuie să creăm un „prod” special cu modulele care se aplică numai producției pentru a preveni acest lucru?

Puțin blocat în utilizarea lui și nu pot face cap sau coadă din documentație.

drapel cn
Există o comandă drush suplimentară pe care trebuie să o adăugați la implementările dvs. Este documentat în modul, dar practic este un import de configurare per mediu.
Puncte:1
drapel de

De exemplu, avem setate Drupal Shield și Drupal Password Policy producție, dar nu vrem să o punem pe dezvoltare. Avem Modulul „shield” și „password_policy” selectat în „dev” divizarea configurației pe care am făcut-o

Aceasta este problema ta. Acest lucru va activa modulele pe Dev, nu pe PROD. Trebuie să creați o divizare separată pentru producție și să adăugați acele module. Apoi va trebui să împingeți configurația. Probabil că va trebui, de asemenea, să activați manual modulele pe PROD după ce ați apăsat diviziunea respectivă. Atunci nu va fi suprascris la următoarea apăsare.

Am scris asta, te poate ajuta ceva: https://www.morpht.com/blog/drupal-8-configuration-part-4-extending-api-contributed-modules

Ex0r avatar
drapel cn
Deci, modul în care funcționează configurația noastră acum, ignoră modulele de pe dev (indiferent dacă sunt instalate sau nu), dar le dezactivează în producție. Am înțeles că atunci când un modul este ignorat într-o configurare, citește core.extension și elimină 1 steag la import. Dacă nu este în divizare, folosește orice se află în configurația implicită activă, care trebuie să aibă modulul activat. Nu așa funcționează de fapt?
Jaypan avatar
drapel de
Dacă puneți o listă neagră pe un modul activat pe DEV, aceasta va fi activată numai pe DEV.
Ex0r avatar
drapel cn
Are sens. Mulțumesc. Voi primi configurarea noastră de configurare a produsului.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.