Cómo evitar que el módulo Devel se instale en entornos de producción

Usando el nuevo administrador de configuración de Drupal 8, ¿cómo puedo evitar que instale el módulo Devel en ciertos entornos? Hasta donde sé, instalarlo en mi local significa que la próxima vez que exporte la configuración y la mueva a mis otros entornos (dev, test, prod), se habilitará automáticamente.

Método: Drush

• Drush puede ignorar los estados habilitados de las extensiones al sincronizar la configuración.

  drush cex --skip-modules=devel

  drush cim --skip-modules=devel

• Con las herramientas Drush CMI puede operar con una lista de configuraciones para ignorar.

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

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

Método: módulos

• Puede usar el módulo de configuración de división que le permite:

  1. Divida alguna configuración en una carpeta dedicada
  2. Configuración de lista negra
  3. Ignorar un conjunto de configuraciones
  4. Configurado por entidades de configuración

• Configuración del módulo de modo de solo lectura

  Este módulo permite bloquear cualquier cambio de configuración realizado a través de la interfaz de usuario del administrador de Drupal. Esto puede ser útil en escenarios en los que, por ejemplo, los cambios de configuración no se deben realizar en el entorno de producción, sino solo en entornos locales o de preparación.

  $settings['config_readonly'] = TRUE;

• Y otro módulo es la configuración del entorno que le permite anular la configuración por entorno.

Actualización : la función que se describe a continuación se eliminó últimamente https://www.drupal.org/project/config_split/issues/2926505

Si está utilizando drush en su proceso de implementación, puede hacer lo siguiente:

Cree un drushrc.phparchivo en el mismo directorio que su settings.php(por ejemplo:) docroot/sites/defaulty coloque lo siguiente:

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

Esto significa que puede manipular los comandos drush cex/ drush cimpara omitir módulos durante su proceso.

Puede leer más sobre el uso del filtro del módulo de configuración en Drush 8 .

drush cex --skip-modulesse eliminó a favor de config_split como se explica en este número, por lo que las soluciones aquí basadas en drush no me han funcionado.

Aquí está la solución basada en la solución Duncanmoo usando el módulo config_exclude

1. Instale config_exclude usando Composer require --dev y configúrelo

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

permitir que settings.php se use en su entorno de desarrollo local

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

Agregue configuraciones config_exclude en el archivo local

$ nano sites/default/setting.local.php

Aquí hay algunas configuraciones de muestra

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

NOTA 1: config_filter es una dependencia config_exclude, por lo que si no necesita producción, puede excluirla arriba

NOTA2: El settings.local.phpno es un requisito. Depende de si es controlado por su VCS o no.

2. Compositor requiere --dev

Al habilitar un módulo que es puramente para desarrollo, use el indicador --dev:

$ composer require --dev drupal/devel

Esto da como resultado que esas dependencias se agreguen al archivo composer.json en require-dev:

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

Entonces, si instala el sitio SIN sus módulos de desarrollo, use:

$ composer install --no-dev

NOTA: En sus entornos de producción y producción, siempre debe hacer --no-dev

3. use drush cex como lo usa normalmente

$ drush cex 

no exportará ninguna de las configuraciones de los módulos excluidos

NOTA: He notado que la configuración de core.extension parece haber sido modificada después de ejecutar el comando anterior, pero el .yml correspondiente nunca se escribe en el disco duro (incluso después de confirmar will be deleted and replaced with the active config), por lo que no hay nada que comprometer, supongo que depende de partes internas del módulo config_exclude

Hay un problema interesante para Drupal 8.3.x: permitir que los módulos de desarrollo se excluyan de la exportación de configuración . El consenso general es que Configuration Split es actualmente la mejor solución.

Comentario de swentel :

Solo quería documentar brevemente cómo funciona config_split: la entidad de configuración de configuración dividida define lo que está en la lista negra, lo que le permite incluir en la lista negra los módulos y / o los objetos de configuración. El ejemplo canónico, el desarrollo, ya tiene un caso de uso interesante: viene con system.menu.devel que, en caso de que desarrolle una lista negra, el archivo de configuración del menú no se eliminará ya que no hay dependencia. Si bien no es un problema importante, la división de configuración también le permite seleccionar eso individualmente para que se elimine en el entorno.

Comentario de geerlingguy :

He probado algunos métodos diferentes para administrar la configuración específica del entorno, y config_split parece alcanzar la usabilidad correcta en comparación con el saldo adicional adicional, el mejor hasta ahora. Es simple y liviano, pero me permite marcar (y continuar usando) cierta configuración solo en ciertos entornos.

Configuración Split podría ser una solución viable para algunos.

La administración de la configuración de Drupal 8 funciona mejor al importar y exportar todo el conjunto de la configuración de los sitios. Sin embargo, a veces a los desarrolladores les gusta optar por la robustez de CM y tienen un superconjunto de configuración activo en su máquina de desarrollo e implementan solo un subconjunto. El ejemplo canónico para esto es tener el módulo de desarrollo habilitado o tener algunas ubicaciones de bloque o vistas en el entorno de desarrollo y luego no exportarlos al conjunto de configuración que se implementará, y aún así poder compartir la configuración de desarrollo con colegas.

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

Hay una buena manera de hacer esto, donde terminas con tus módulos de desarrollo comprometidos en el compositor por conveniencia y la configuración de esos módulos no se agrega a tu exportación de configuración (hay 2 partes):

1. Composer requiere --dev Cuando habilite un módulo que es puramente para desarrollo, use el indicador --dev:

$ composer require --dev drupal/devel

Esto da como resultado que esas dependencias se agreguen al archivo composer.json en require-dev:

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

Entonces, si instala el sitio SIN sus módulos de desarrollo, dice:

$ composer install --no-dev

NB: en sus entornos de producción y producción, siempre debe hacer --no-dev

2. Use el módulo config_split

El módulo de división de configuración le permite crear agrupaciones de exportación de configuración que se pueden habilitar o deshabilitar en un entorno.

En realidad tengo 3 divisiones:

1. Configuración del sitio principal (habilitado en todas partes; desarrollo y puesta en escena y producción)
2. Configuración provisional (habilitada en desarrollo y preparación): incluye el módulo de redireccionamiento de correo electrónico
3. Configuración de desarrollo: incluye desarrollo, tipo ... pero no redirige el correo electrónico, ya que viene con tener la configuración de preparación habilitada en desarrollo.

Hice un pequeño guión para hacerlo todo de una 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

También puede ver el módulo Ignorar configuración .

Este módulo es una herramienta que le permite mantener la configuración que desea en su lugar.

Digamos que le gustaría que la configuración de system.site (que contiene el nombre del sitio, el eslogan, el correo electrónico, etc.) permanezca intacta, en su sitio en vivo, sin importar la configuración, en la carpeta de exportación.

¿O tal vez se está cansando de cambiar los ajustes de desarrollo cada vez que importa la configuración?

Puede usar un módulo de anulación de implementación para esto. Lea el siguiente enlace para obtener una descripción detallada:

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

Sin embargo , la mejor forma de hacerlo sería deshabilitar su módulo en local y luego exportar la configuración.

Drupal proporciona una forma de anular los ajustes de configuración settings.php, pero no son válidos para deshabilitar / habilitar 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.
 */