Como impedir que o módulo Devel seja instalado nos ambientes de produção

Usando o novo gerenciador de configuração do Drupal 8, como posso impedir que ele instale o módulo Devel em determinados ambientes? Tanto quanto sei, instalá-lo no meu local significa que na próxima vez que exportar a configuração e movê-la para meus outros ambientes (dev, test, prod), ela será automaticamente ativada.

Método: Drush

• O drush pode ignorar os estados de extensões ativados ao sincronizar a configuração.

  drush cex --skip-modules=devel

  drush cim --skip-modules=devel

• Com as ferramentas Drush CMI, você pode operar com uma lista de configurações a serem ignoradas.

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

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

Método: Módulos

• Você pode usar o módulo Split de configuração que permite:

  1. Dividir algumas configurações na pasta dedicada
  2. Configuração da lista negra
  3. Ignorar um conjunto de configurações
  4. Configurado por entidades de configuração

• Módulo de modo somente leitura de configuração

  Este módulo permite bloquear qualquer alteração na configuração feita através da interface do usuário do administrador do Drupal. Isso pode ser útil em cenários em que, por exemplo, mudanças na configuração não devem ser feitas no ambiente de produção, mas apenas em ambientes temporários ou locais.

  $settings['config_readonly'] = TRUE;

• E outro módulo é a configuração do ambiente que permite substituir a configuração por ambiente.

Atualização : o recurso descrito abaixo foi removido recentemente https://www.drupal.org/project/config_split/issues/2926505

Se você estiver usando drush em seu processo de implantação, poderá fazer o seguinte:

Crie um drushrc.phparquivo no mesmo diretório que o seu settings.php(por exemplo docroot/sites/default:) e coloque o seguinte:

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

Isso significa que você pode manipular os comandos drush cex/ drush cimpara ignorar os módulos durante seu processo.

Você pode ler mais sobre Como usar o filtro do módulo de configuração no Drush 8 .

drush cex --skip-modulesfoi removido em favor do config_split, conforme explicado nesta edição, portanto, as soluções aqui baseadas em drush não funcionaram para mim.

Aqui está a solução baseada na solução Duncanmoo usando o módulo config_exclude

1. Instale config_exclude usando o Composer require --dev e configure-o

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

permita que o settings.php seja usado no seu ambiente de desenvolvimento local

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

Adicionar configurações config_exclude no arquivo local

$ nano sites/default/setting.local.php

aqui estão algumas configurações de amostra

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

NOTA1: config_filter é uma dependência config_exclude, portanto, se você não precisar da produção, poderá excluí-lo acima

NOTA 2: O settings.local.phpnão é um requisito. Depende se é controlado pelo seu VCS ou não.

2. O compositor exige --dev

Ao habilitar um módulo puramente para desenvolvimento, use o sinalizador --dev:

$ composer require --dev drupal/devel

Isso resulta no acréscimo dessas dependências no arquivo composer.json em require-dev:

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

Portanto, se você instalar o site SEM seus módulos de desenvolvimento, use:

$ composer install --no-dev

NOTA: Nos ambientes de preparação e produção, você sempre deve fazer --no-dev

3. use drush cex como você normalmente usa

$ drush cex 

não exportará nenhuma das configurações de módulos excluídos

NOTA: Tenho notado core.extension configurações parecem ter sido modificado após a execução do comando acima, mas o .yml correspondente nunca é escrita no disco rígido (mesmo após a confirmação will be deleted and replaced with the active config) então não há nada a ser comprometidos, eu acho que depende do internos do módulo config_exclude

Há uma questão interessante para o Drupal 8.3.x: permita que os módulos de desenvolvimento optem por não participar da configuração de exportação . O consenso geral é que atualmente a Divisão de Configuração é a melhor solução.

Comentado por swentel :

Só queria documentar brevemente como o config_split funciona: A entidade de configuração da divisão de configuração define o que está na lista negra, permitindo que você faça a lista negra de módulos e / ou objetos de configuração. O exemplo canônico, sendo devel, já possui um caso de uso interessante: ele vem com system.menu.devel que, caso você desista da lista negra, o arquivo de configuração do menu não será removido, pois não há dependência. Embora não seja um problema grave, a divisão de configuração permite que você a selecione individualmente, para que seja removida do ambiente.

Comentado por geerlingguy :

Eu tentei alguns métodos diferentes de gerenciar configurações específicas do ambiente, e o config_split parece ter a usabilidade certa versus o saldo extra adicional, o melhor até agora. É simples e leve, mas me permite marcar (e continuar a usar) determinadas configurações apenas em determinados ambientes.

A divisão de configuração pode ser uma solução viável para alguns.

O gerenciamento de configuração do Drupal 8 funciona melhor ao importar e exportar todo o conjunto da configuração de sites. No entanto, às vezes os desenvolvedores gostam de optar pela robustez do CM e têm um superconjunto de configuração ativo em sua máquina de desenvolvimento e implantam apenas um subconjunto. O exemplo canônico disso é ter o módulo devel ativado ou ter algumas veiculações ou visualizações de bloco no ambiente de desenvolvimento e não exportá-las para o conjunto de configurações a serem implantadas, mas ainda assim poder compartilhar a configuração de desenvolvimento com os colegas.

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

Há uma maneira elegante de fazer isso, em que você acaba com os módulos de desenvolvimento comprometidos no compositor por conveniência e a configuração desses módulos não é adicionada à sua exportação de configuração (existem duas partes):

1. O compositor exige --dev Ao habilitar um módulo que é apenas para desenvolvimento, use o sinalizador --dev:

$ composer require --dev drupal/devel

Isso resulta no acréscimo dessas dependências no arquivo composer.json em require-dev:

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

Portanto, se você instalar o site SEM seus módulos de desenvolvimento, dirá:

$ composer install --no-dev

NB: Nos seus ambientes de preparação e produção, você sempre deve fazer --no-dev

2. Use o módulo config_split

O módulo de divisão de configuração permite criar agrupamentos de exportação de configuração que podem ser ativados ou desativados em um ambiente.

Na verdade, tenho 3 divisões:

1. Configuração do site principal (ativada em qualquer lugar; desenvolvimento, preparação e produção)
2. Configuração de armazenamento temporário (ativada no desenvolvimento e armazenamento temporário) - inclui redirecionar o módulo de email
3. Configuração do desenvolvedor - inclui devel, kint ... mas não redireciona o e-mail, pois é fornecido com a configuração de teste ativada no dev.

Fiz um pequeno roteiro para fazer tudo de uma só vez.

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

Você também pode ver o módulo Config Ignore .

Este módulo é uma ferramenta para permitir que você mantenha a configuração desejada.

Digamos que você queira que a configuração system.site (que contém o nome, o slogan, o email, etc) dos sites permaneça intocada no site ao vivo, independentemente da configuração, na pasta de exportação.

Ou talvez você esteja cansado de alterar o devel.settings toda vez que importar a configuração?

Você pode usar um módulo de substituição de implantação para isso. Leia o link a seguir para obter uma descrição detalhada:

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

No entanto , a melhor maneira de fazer isso seria desativar o módulo no local e exportar a configuração.

O Drupal fornece uma maneira de substituir as definições de configuração settings.php, mas elas não são válidas para desativar / ativar os módulos.

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