Exclure la configuration de l'importation / exportation

Je pensais que c'était un cas d'utilisation simple du nouveau système de gestion de configuration, mais je n'ai pas eu de chance de trouver comment résoudre ce problème:

Problème

Je veux stocker la configuration dans git et utiliser drush pour exporter la configuration pendant le développement, puis lors du déploiement, importer la configuration. Assez similaire à faire un retour de fonctionnalités dans Drupal 7. Mon problème est que je ne veux pas stocker les codes d'accès dans git pour diverses intégrations. Cela entraîne la suppression de ces configurations sur
$ drush cim -y

Où j'ai regardé

J'espérais qu'il y aurait une liste / configuration simple pour les configurations qui devraient être exclues lors de l'importation / exportation. Il semble qu'il y en ait eu à un moment donné, mais il doit avoir été supprimé à nouveau, car il est disponible dans la version actuelle de Drupal 8.

J'ai regardé comment les changements de configuration sont effectués en comparant la mémoire active et la synchronisation pour voir s'il y a un endroit où je pourrais supprimer les modifications, cela ne semble pas être le cas. J'ai regardé à quel point la configuration importait drush car elle a des exclusions de configuration, mais il ne semblait pas que c'était extensible. J'ai regardé ConfigEvents, mais tout cela semble se produire après une importation, il ne semble donc pas que cela puisse être utilisé.

Suis-je en train de manquer quelque chose, ou n'est-il pas possible d'exclure simplement les configurations de l'importation / exportation?

Il n'est pas possible d'avoir des exclus spécifiquement, mais il y a quelque chose.

Tout comme $ conf dans Drupal 7, il y a $ config dans settings.php que vous pouvez utiliser pour remplacer n'importe quoi dans la configuration localement. Le format est $config['name.of.config']['nested']['key'].

Notez que tout ce qui est stocké dans la configuration est toujours dans git, vous devez donc en conserver aucun ou tester vos codes d'accès dans git. De plus, l'interface utilisateur montrera ce qui est réellement stocké dans la configuration et ne fournira actuellement aucune indication qu'il est remplacé. Il y a des problèmes en suspens pour améliorer cela.

Je comprends que cela a des limites mais pour le moment, il n'est pas possible de garder quelque chose en dehors de la configuration exportée. Pour autant que je sache.

Vous pouvez utiliser le module "Config Ignore": https://www.drupal.org/project/config_ignore

Avez-vous déjà ressenti que la configuration de votre site avait été remplacée par la configuration sur le système de fichiers, lorsque vous faites un cim drush?

Plus maintenant!

Ce module est un outil pour vous permettre de conserver la configuration souhaitée, en place.

Vous pouvez utiliser une combinaison de config_ignore et config_split pour cela.

Config ignore vous permet d'ignorer un sous-ensemble d'entités de configuration lors de l'importation (empêche également les suppressions depuis la version 2.x). Malheureusement, cela n'empêche pas d'exclure la configuration pendant l'exportation.

Pour exclure des entités de configuration lors de l'exportation, vous pouvez utiliser config_split, créer une nouvelle entité config_split et laisser le dossier vide. Cela empêche la configuration d'être exportée vers le système de fichiers; au lieu de cela, il l'exporte dans la base de données.

J'ai écrit Exclure la configuration de la gestion de la configuration dans Drupal 8 sur ce sujet.

Afin de diviser les configurations, vous pouvez utiliser https://www.drupal.org/project/config_split .

Entrez config_split qui fournit une commande de console Drupal pour importer et exporter la configuration filtrée. L'intégration de Drush devrait suivre bientôt (après tout, le filtre est inspiré par le filtre --skip-modules de drush).

Vous pouvez diviser les exportations en différents répertoires que vous pouvez ensuite ignorer.

Il y a eu une très belle présentation à drupal con dublin 2016 par les responsables de l'initiative CMI que je vous invite à vérifier quoi qu'il arrive.

Je viens de tester @berdir dans la réponse n ° 1 et il fonctionne parfaitement. Seulement j'ajoute une petite note: il faut mettre toute la config dans ce var, complet. Sans cela, $ config var ne fonctionne pas correctement.

Quelque chose comme ça:

 $config['language.negotiation'] = array(
  'session' => array(
    'parameter' => 'language',
  ),
  'url' => array(
    'source' => 'domain',
    'prefixes' => array(
      'es' => '',
      'pt-br' => '',
    ),
    'domains' => array(
      'es' => 'YourLocalDomain',
      'pt-br' => 'Anotherlocaldomain',
    ),
  ),
  'selected_langcode' => 'site_default',
  'langcode' => 'es',
);

Documentation: https://www.drupal.org/node/1928898

Remarque de la documentation ci-dessus: "Notez que les valeurs remplacées via $ config dans settings.php ne seront pas visibles depuis l'interface d'administration Drupal."

Je me demande un peu pourquoi personne n'a mentionné les outils Drush CMI à ce jour. Les mots magiques sont drush cexyet config-ignore.yml. Vous aurez une liste que vous pourrez ajuster. Nous en avons eu besoin une fois pour exclure les instances de bloc tandis que les bases de bloc étaient traitées.

Nous voulons exporter toutes les configurations, mais nous voulons exclure certains modèles.

C'est là que l' --ignore-listoption drush cexyentre en jeu.

Dans notre projet, nous avons un dossier ./drush, donc nous collons un fichier dans leur appelé config-ignore.yml avec le contenu comme suit.

ignore:
  - field.field.contact_message.*
  - field.storage.contact_message.*
  - contact.form.*
  - core.entity_form_display.contact_message*
  - core.entity_form_display.contact_form*
  - core.entity_view_display.contact_message*
  - core.entity_view_display.contact_form*
  - system.site
  - workbench_email.workbench_email_template.*

Alors maintenant on court drush cexycomme ça

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

Donc, cela exporte la configuration active, puis applique la liste des ignorés pour supprimer la configuration indésirable.

Alors maintenant, lorsque vous exécutez, git statusvous ne devriez voir que les modifications que vous souhaitez valider.

Source: https://www.previousnext.com.au/blog/introducing-drush-cmi-tools

Installation

cd ~/.drush
wget https://raw.githubusercontent.com/previousnext/drush_cmi_tools/8.x-1.x/drush_cmi_tools.drush.inc
drush cc drush

Source: https://github.com/previousnext/drush_cmi_tools

Utilisation du partage de configuration (recommandé)

Le module de configuration config a été spécialement conçu pour ce besoin.

Config split est intégré avec drush.

Utiliser Drush uniquement

Drush, il est également censé pouvoir le faire en utilisant le --skip-modulesdrapeau.

Vous pouvez ajouter les lignes suivantes dans un drupal / drushrc.php dans la racine Web de votre projet pour le faire automatiquement.

$command_specific['config-export']['skip-modules'] = array('devel');
$command_specific['config-import']['skip-modules'] = array('devel');

Voir http://www.drush.org/en/master/config-exporting/#ignoring-development-modules

Malheureusement, il existe un bogue avec cette fonctionnalité: https://github.com/drush-ops/drush/issues/1820 . Donc, pour le moment, vous devez également ajouter ces fichiers de configuration dans votre .gitignore afin que les fichiers de configuration exportés ne soient pas validés. C'est un processus en cours pour peut-être abandonner cette fonctionnalité (buggy) de drush en faveur de la division de la configuration.