Come impedire l'installazione del modulo Devel su ambienti di produzione

Utilizzando il nuovo Drupal 8 Configuration Manager, come posso impedirgli di installare il modulo Devel su determinati ambienti? Per quanto ne so, installarlo sul mio locale significa che la prossima volta che esporterò la configurazione e la sposterò negli altri miei ambienti (sviluppo, test, prod), verrà automaticamente abilitato.

Metodo: Drush

• Drush può ignorare gli stati di estensione abilitati durante la sincronizzazione della configurazione.

  drush cex --skip-modules=devel

  drush cim --skip-modules=devel

• Con gli strumenti Drush CMI è possibile operare con un elenco di configurazioni da ignorare.

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

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

Metodo: moduli

• È possibile utilizzare il modulo Split configurazione che consente di:

  1. Dividi alcune configurazioni in una cartella dedicata
  2. Configurazione della lista nera
  3. Ignora un set di configurazione
  4. Configurato da entità di configurazione

• Configurazione Modulo modalità sola lettura

  Questo modulo consente di bloccare eventuali modifiche alla configurazione effettuate tramite l'interfaccia utente dell'amministratore di Drupal. Ciò può essere utile in scenari in cui, ad esempio, le modifiche alla configurazione non devono essere eseguite nell'ambiente di produzione, ma solo in ambienti di gestione temporanea o locali.

  $settings['config_readonly'] = TRUE;

• E un altro modulo è la configurazione dell'ambiente che consente di sovrascrivere la configurazione in base all'ambiente.

Aggiornamento : la funzionalità descritta di seguito è stata rimossa di recente https://www.drupal.org/project/config_split/issues/2926505

Se si utilizza drush nel processo di distribuzione, è possibile effettuare le seguenti operazioni:

Crea un drushrc.phpfile nella stessa directory del tuo settings.php(ad esempio:) docroot/sites/defaulte inserisci quanto segue:

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

Questo significa che puoi manipolare i comandi drush cex/ drush cimper saltare i moduli, durante il loro processo.

Puoi leggere ulteriori informazioni sull'uso del filtro del modulo di configurazione in Drush 8 .

drush cex --skip-modulesè stato rimosso a favore di config_split come spiegato in questo numero, quindi le soluzioni qui basate su drush non hanno funzionato per me.

Ecco la soluzione basata sulla soluzione Duncanmoo che utilizza il modulo config_exclude

1. Installa config_exclude usando Composer richiede --dev e configuralo

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

consenti settings.php da usare nel tuo ambiente di sviluppo locale

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

Aggiungi le impostazioni di config_exclude nel file locale

$ nano sites/default/setting.local.php

ecco alcune impostazioni di esempio

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

NOTA 1: config_filter è una dipendenza config_exclude quindi se non ti serve la produzione puoi escluderla sopra

NOTA 2: Il settings.local.phpnon è un requisito. Dipende se è controllato dal VCS o meno.

2. Il compositore richiede --dev

Quando si abilita un modulo che è puramente per lo sviluppo, utilizzare il flag --dev:

$ composer require --dev drupal/devel

Ciò comporta l'aggiunta di tali dipendenze nel file composer.json in request-dev:

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

Quindi se installi il sito SENZA i tuoi moduli di sviluppo usi:

$ composer install --no-dev

NOTA: nei tuoi ambienti di staging e prod, dovresti sempre fare --no-dev

3. utilizzare drush cex come si usa normalmente

$ drush cex 

non esporterà nessuna delle impostazioni dei moduli esclusi

NOTA: ho notato che le impostazioni di core.extension sembrano essere state modificate dopo aver eseguito il comando sopra, ma il corrispondente .yml non viene mai scritto sul disco rigido (anche dopo aver confermato will be deleted and replaced with the active config) quindi non c'è nulla da impegnare, immagino che dipenda dal interni del modulo config_exclude

C'è un problema interessante per Drupal 8.3.x: consentire ai moduli di sviluppo di annullare la configurazione di esportazione . Il consenso generale è che la suddivisione della configurazione è attualmente la soluzione migliore.

Commento di swentel :

Volevo solo documentare brevemente come funziona config_split: l'entità config config config definisce ciò che è nella lista nera, permettendoti di inserire nella blacklist i moduli e / o gli oggetti di configurazione. L'esempio canonico, essendo in fase di sviluppo, ha già un caso d'uso interessante: viene fornito con system.menu.devel che, nel caso in cui si sviluppi una lista nera, il file di configurazione del menu non verrà rimosso poiché non vi è dipendenza. Anche se non è un grosso problema, la configurazione config ti consente di selezionare singolarmente anche quello, quindi viene rimosso sull'ambiente.

Commento di geerlingguy :

Ho provato alcuni metodi diversi per gestire la configurazione specifica per l'ambiente, e config_split sembra colpire la giusta usabilità contro un ulteriore sovraccarico finora. È semplice e leggero, ma mi consente di contrassegnare (e continuare a utilizzare) determinate configurazioni solo in determinati ambienti.

La suddivisione della configurazione potrebbe essere una soluzione praticabile per alcuni.

La gestione della configurazione di Drupal 8 funziona al meglio durante l'importazione e l'esportazione dell'intero set della configurazione dei siti. Tuttavia, a volte agli sviluppatori piace rinunciare alla solidità di CM e avere un super-set di configurazione attivo sulla propria macchina di sviluppo e distribuire solo un sottoinsieme. L'esempio canonico per questo è avere il modulo di sviluppo abilitato o avere alcuni posizionamenti di blocchi o viste nell'ambiente di sviluppo e quindi non esportarli nel set di configurazione da distribuire, pur essendo in grado di condividere la configurazione di sviluppo con i colleghi.

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

C'è un modo accurato per farlo, in cui finisci con i tuoi moduli dev impegnati in compositore per comodità e la configurazione di quei moduli non viene aggiunta alla tua esportazione di configurazione (ci sono 2 parti):

1. Il compositore richiede --dev Quando si abilita un modulo che è puramente per lo sviluppo, utilizzare il flag --dev:

$ composer require --dev drupal/devel

Ciò comporta l'aggiunta di tali dipendenze nel file composer.json in request-dev:

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

Quindi se installi il sito SENZA i tuoi moduli di sviluppo dici:

$ composer install --no-dev

NB: Nei tuoi ambienti di staging e prod, dovresti sempre fare --no-dev

2. Utilizzare il modulo config_split

Il modulo di suddivisione della configurazione consente di creare raggruppamenti di esportazione della configurazione che possono essere abilitati o disabilitati in un ambiente.

In realtà ho 3 divisioni:

1. Configurazione del sito principale (abilitata ovunque; sviluppo, stadiazione e produzione)
2. Configurazione della gestione temporanea (abilitata in sviluppo e gestione temporanea): include il modulo di reinstradamento della posta elettronica
3. Dev config - include devel, kint ... ma non reindirizzare la posta elettronica poiché viene fornito con la configurazione della gestione temporanea abilitata in dev.

Ho realizzato una piccola sceneggiatura per fare tutto in un colpo solo.

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

Puoi anche vedere il modulo Config Ignore .

Questo modulo è uno strumento che ti consente di mantenere la configurazione desiderata, in atto.

Supponiamo che tu voglia che la configurazione di system.site (che contiene il nome, lo slogan, l'e-mail, ecc.) Del sito rimanga intatta, sul tuo sito live, indipendentemente dalla configurazione, nella cartella di esportazione.

O forse ti stai stancando di cambiare le impostazioni devel.sett ogni volta che importi la configurazione?

A tale scopo è possibile utilizzare un modulo di override di distribuzione. Leggi il seguente link per una descrizione dettagliata:

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

Tuttavia , il modo migliore per farlo sarebbe disabilitare il modulo in locale e quindi esportare la configurazione.

Drupal fornisce un modo per sovrascrivere le impostazioni di configurazione settings.php , ma non sono valide per disabilitare / abilitare i moduli.

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