Configuration Split

Module Drupal Illustration Voir sur Drupal.org
Nb téléchargements : 66031

Components

  • Code
  • Documentation
  • Miscellaneous
  • User interface

Documentation

Ecosystem

Licence

http://www.gnu.org/licenses/old-licenses/gpl-2.0.html

permet d'avoir une config de dév et une autre config sur la recette ou la prod. Exemple : develmodule activé ou d'avoir quelques placements de blocs ou vues dans l'environnement de développement, puis de ne pas les exporter dans l'ensemble de configuration à déployer

Release

Status : Published
Projects : Modules
Maintenance status : Actively maintained
Development status : Under active development
Supported Branches : 2.0., 8.x-1.
shield Stable releases for this project are covered by the security advisory policy.


Description

Background

The Drupal 8+ configuration management works best when importing and exporting the whole set of the sites configuration. However, sometimes developers like to opt out of the robustness of CM and have a super-set of configuration active on their development machine and deploy only a subset. The canonical example for this is to have the devel module enabled or having a few block placements or views in the development environment and then not export them into the set of configuration to be deployed, yet still being able to share the development configuration with colleagues.

This module allows to define sets of configuration that will get exported to separate directories when exporting, and get merged together when importing. It is possible to define in settings.php which of these sets should be active and considered for the export and import.

Documentation

Video and Slides from the Drupalcon Vienna presentation.

Help to improve the online documentation.

Notice

The important part to remember is to use Drupal 8s configuration management the way it was intended to be used. This module does not interfere with the active configuration but instead filters on the import/export pipeline.
If you use this module you should have a staging environment where you can let the configuration management do its job and verify that everything is good for deployment.

How it works

When importing config, the configuration is read from the main sync directory and also from split directories. Drupal is presented with the unified configuration of the sync directory and the extra configuration defined in splits.
Importing and exporting works the same way as before, except some configuration is read from and written to different directories. Importing configuration still removes configuration not present in the files. Thus, the robustness and predictability of the configuration management remains.

Upgrade from version 1.x to 2.x

Be sure to run the update hooks so that the configuration is switched to use the new schema. As with any module update that changes configuration: do not forget to export the site configuration after the update hooks have run in your development environment.

Attention: 1.x depended on Config Filter, but 2.x uses the core API. If you have not explicitly required Config Filter before Composer will remove it when updating. But then you are left with a drupal module still being installed but no longer available in the code base.
In order to properly uninstall Config Filter you should explicitly require it and then uninstall it, and remove it from composer.json only in a later deployment.

Key difference: 1.x could only split the whole config files. 2.x can split individual keys by creating a "config patch" file. This is turned on by default and you can switch it back to the 1.x behaviour by configuring your split to "Do not patch dependents".



Toutes les informations proviennent du site drupal.org