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

26

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.

cambraca
fuente
¿Está usando drushaceptable? Me enteré el otro día sobre drush config-export --skip-modules=devel. Puede haber algo similar sin usar drush, pero no lo sé.
mradcliffe 01 de
¿Entonces tendría que hacer eso cada vez que exporto la configuración? Tiene que haber una mejor manera: |
cambraca 01 de
Tal vez pueda agregar algunos archivos de configuración a su .gitignore.
digitaldonkey
1
Esto está relacionado: drupal.stackexchange.com/questions/185536/…
Les Lim
2
Creo que esta pregunta es demasiado amplia en retrospectiva. Probablemente hay muchas buenas respuestas porque depende del proceso de compilación y desarrollo del sitio.
mradcliffe el

Respuestas:

18

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.

Adrian Cid Almaguer
fuente
2
Realmente no me gusta tener todas las dependencias de la biblioteca para el módulo de desarrollo en mis servidores de producción, así que lo agrego al compositor usando composer require --dev drupal/devel. La ventaja adicional es que la instalación del compositor es más rápida, lo que hace que la implementación de productos sea más rápida.
Duncanmoo
6

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 .

ssibal
fuente
5

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

GiorgosK
fuente
Tuve una experiencia muy similar a @GiorgosK siguiendo las sugerencias anteriores. Esta solución funcionó perfectamente para mí y también contiene consejos bien pensados. También noté falsos negativos de core.extension pero de hecho NO cambió el estado de git, así que todo está bien. Gracias
vrwired
2

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.

Wim Mostrey
fuente
2

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

Kevin
fuente
+1 para la división de configuración, siempre uso eso para tener Devel y otros módulos como Field UI y Views UI deshabilitados en prod. Consulte Deshabilitar módulos usando la división de configuración .
leymannx
2

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.
Duncanmoo
fuente
1
Realmente no deberías usar dependencias de desarrollo de esta manera. Son más para herramientas, como sniffer de código, que no necesitaría ejecutar en producción. Si están habilitados y Drupal espera que se instale el módulo y el código no esté allí, esto podría conducir a la inestabilidad del sitio. Drupal / Composer aún podría intentar cargar un archivo que no está en el sistema de archivos si es una dependencia de desarrollo.
Frank Robert Anderson el
@FrankRobertAnderson, ¿no propone una solución mejor? No quiero desarrollar módulos o bibliotecas dependientes en mi servidor de producción, ¿qué propones?
Duncanmoo
Drupal realmente no ofrece una buena opción para esto. Su plan no es horrible, pero generará problemas si no tiene cuidado. El problema que tengo con su plan es config_split se convierte en el pin en el que depende todo su sitio. Yo votaría el tuyo si no fuera por la dependencia de desarrollo, que ni siquiera era una pregunta en el OP.
Frank Robert Anderson
1

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
Roebrt Brown
fuente
1

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?

DRUPWAY
fuente
El módulo Ignorar configuración no es adecuado en este caso. Desde la página del módulo: no ignore la configuración de core.extension, ya que le impedirá habilitar nuevos módulos con una importación de configuración. Use el módulo Config Split para módulos específicos del entorno.
bmunslow
1

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.
 */
kmdhrm
fuente