Comment empêcher l'installation du module Devel sur les environnements de production

À l'aide du nouveau gestionnaire de configuration Drupal 8, comment puis-je l'empêcher d'installer le module Devel sur certains environnements? Pour autant que je sache, l'installer sur mon local signifie que la prochaine fois que j'exporterai la configuration et la déplacerai vers mes autres environnements (dev, test, prod), elle sera automatiquement activée.

Méthode: Drush

• Drush peut ignorer les états activés des extensions lors de la synchronisation de la configuration.

  drush cex --skip-modules=devel

  drush cim --skip-modules=devel

• Avec les outils Drush CMI, vous pouvez utiliser une liste de configurations à ignorer.

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

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

Méthode: modules

• Vous pouvez utiliser le module Configuration Split qui vous permet de:

  1. Répartir une configuration dans un dossier dédié
  2. Configuration de la liste noire
  3. Ignorer un ensemble de configuration
  4. Configuré par des entités de configuration

• Configuration Module en mode lecture seule

  Ce module permet de verrouiller toutes les modifications de configuration effectuées via l'interface d'administration Drupal. Cela peut être utile dans des scénarios où, par exemple, les modifications de configuration ne doivent pas être effectuées sur l'environnement de production, mais uniquement sur les environnements intermédiaires ou locaux.

  $settings['config_readonly'] = TRUE;

• Et un autre module est la configuration de l' environnement qui vous permet de remplacer la configuration en fonction de l'environnement.

Mise à jour : la fonctionnalité décrite ci-dessous a été supprimée récemment https://www.drupal.org/project/config_split/issues/2926505

Si vous utilisez drush dans votre processus de déploiement, vous pouvez effectuer les opérations suivantes:

Créez un drushrc.phpfichier dans le même répertoire que votre settings.php(par exemple:) docroot/sites/defaultet mettez ce qui suit:

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

Cela signifie que vous pouvez manipuler les commandes drush cex/ drush cimpour ignorer les modules pendant leur processus.

Vous pouvez en savoir plus sur l' utilisation du filtre du module de configuration dans Drush 8 .

drush cex --skip-modulesa été supprimé en faveur de config_split comme expliqué dans ce numéro, donc les solutions basées sur drush n'ont pas fonctionné pour moi.

Voici la solution basée sur la solution Duncanmoo utilisant le module config_exclude

1. Installez config_exclude à l'aide de Composer require --dev et configurez-le

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

autorisez settings.php à être utilisé sur votre environnement de développement local

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

Ajouter des paramètres config_exclude dans un fichier local

$ nano sites/default/setting.local.php

voici quelques exemples de paramètres

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

NOTE 1: config_filter est une dépendance config_exclude donc si vous n'en avez pas besoin de production vous pouvez l'exclure ci-dessus

REMARQUE 2: le settings.local.phpn'est pas une exigence. Cela dépend si est contrôlé par votre VCS ou non.

2. Le compositeur requiert --dev

Lorsque vous activez un module qui est purement pour le développement, utilisez le drapeau --dev:

$ composer require --dev drupal/devel

Cela entraîne l'ajout de ces dépendances dans le fichier composer.json sous require-dev:

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

Donc, si vous installez le site SANS vos modules de développement que vous utilisez:

$ composer install --no-dev

REMARQUE: Sur vos environnements de production et de production, vous devez toujours faire --no-dev

3. utilisez drush cex comme vous l'utilisez normalement

$ drush cex 

n'exportera aucun des paramètres des modules exclus

REMARQUE: j'ai remarqué que les paramètres core.extension semblent avoir été modifiés après avoir exécuté la commande ci-dessus mais le .yml correspondant n'est jamais écrit sur le disque dur (même après confirmation will be deleted and replaced with the active config) donc il n'y a rien à commettre, je suppose que cela dépend de la internes du module config_exclude

Il y a un problème intéressant pour Drupal 8.3.x: permettre aux modules de développement de désactiver la configuration-export . Le consensus général est que Configuration Split est actuellement la meilleure solution.

Commentaire de swentel :

Je voulais juste documenter brièvement le fonctionnement de config_split: l'entité config split config définit ce qui est sur liste noire, vous permettant de mettre sur liste noire les modules et / ou les objets de configuration. L'exemple canonique, étant devel, a déjà un cas d'utilisation intéressant: il est livré avec system.menu.devel qui, dans le cas où vous mettez sur liste noire devel, le fichier de configuration du menu ne sera pas supprimé car il n'y a pas de dépendance. Bien que ce ne soit pas un problème majeur, le partage de configuration vous permet de le sélectionner individuellement afin qu'il soit supprimé sur l'environnement.

Commentaire de geerlingguy :

J'ai essayé quelques méthodes différentes de gestion de la configuration spécifique à l'environnement, et config_split semble atteindre le meilleur niveau de convivialité par rapport à la surcharge supplémentaire. C'est simple et léger, mais cela me permet de marquer (et de continuer à utiliser) certaines configurations uniquement dans certains environnements.

Configuration Split pourrait être une solution viable pour certains.

La gestion de la configuration de Drupal 8 fonctionne mieux lors de l'importation et de l'exportation de l'ensemble de la configuration des sites. Cependant, parfois, les développeurs aiment se retirer de la robustesse de CM et avoir un super-ensemble de configuration actif sur leur machine de développement et déployer uniquement un sous-ensemble. L'exemple canonique pour cela est d'avoir le module de développement activé ou d'avoir quelques emplacements de bloc ou vues dans l'environnement de développement, puis de ne pas les exporter dans l'ensemble de configuration à déployer, tout en étant toujours en mesure de partager la configuration de développement avec des collègues.

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

Il y a une bonne façon de le faire, où vous vous retrouvez avec vos modules de développement commis dans le compositeur pour plus de commodité et la configuration de ces modules n'est pas ajoutée à votre exportation de configuration (il y a 2 parties):

1. Le compositeur requiert --dev Lorsque vous activez un module uniquement pour le développement, utilisez le drapeau --dev:

$ composer require --dev drupal/devel

Cela entraîne l'ajout de ces dépendances dans le fichier composer.json sous require-dev:

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

Donc, si vous installez le site SANS vos modules de développement, vous dites:

$ composer install --no-dev

NB: Sur vos environnements de mise en scène et de production, vous devriez toujours faire --no-dev

2. Utilisez le module config_split

Le module de configuration fractionnée vous permet de créer des regroupements d'export de configuration qui peuvent être activés ou désactivés dans un environnement.

J'ai en fait 3 divisions:

1. Configuration du site principal (activée partout; développement et mise en scène et production)
2. Configuration de la mise en scène (activée dans le développement et la mise en scène) - inclut le module de redirection de messagerie
3. Configuration de développement - inclut devel, kint ... mais pas de redirection de l'e-mail car cela inclut l'activation de la configuration de transfert dans le développement.

J'ai fait un petit script pour tout faire en une seule fois.

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

Vous pouvez également voir le module Config Ignore .

Ce module est un outil pour vous permettre de conserver la configuration que vous souhaitez, en place.

Disons que vous souhaitez que la configuration de system.site (qui contient le nom, le slogan, l'e-mail, etc.) reste intacte sur votre site en direct, quelle que soit la configuration, dans le dossier d'exportation.

Ou peut-être que vous en avez assez de voir les paramètres devel.settings modifiés à chaque fois que vous importez la configuration?

Vous pouvez utiliser un module de remplacement de déploiement pour cela. Lisez le lien suivant pour une description détaillée:

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

Cependant , la meilleure façon de procéder serait de désactiver votre module en local puis d'exporter la configuration.

Drupal fournit un moyen de remplacer les paramètres de configuration dans settings.php, mais ils ne sont pas valides pour désactiver / activer les modules.

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