Possible options to export and import configuration files

Drupal 8 solve configuration using Drush cex cim

Update (Jan 2018) : Definitely use config_split module.

This post was inspired by a situation where I found myself today so this post could also be named as "solving configuration workflow problem in Drupal 8 manually which you should never do because your team have a fast, reliable and automated deployment process which never fails".

There are some different configuration management workflow or pipeline strategies for Drupal 8 already available but there are no undisputed winner yet. Meaning that someone has solved the problem and found a perfect solution which always works and it has become a standard in the community. Why? Because there also different workflows, teams, tools, deployment processes, environments and situations where one need to export and import configuration to another project or environment. If you watch the brilliant presentation [1] from the creators of config_split module you get the idea how complex the issue is.

Because "every" setting or configuration (depends where you draw the line between content and configuration) is in a .yml file you should be able to export it and import it easily to another project or environment. What makes this complicated is that you sometimes want to export all configuration or just some of them.

Usually the challenges which occur are:

  • You need different modules or configuration enabled in different environments. E.g. Development and production server have different modules enabled.
  • You don't want to override or reset settings on production. E.g. ID number for every registration.
  • Don't mess up (change or override) anything which are updated after the last time you did the deployment. E.g. The end user has done some configuration changes in production environment.

Therefore standard trivial drush config-export (cex) and config-import (cim) does not work in practise even if you just transport (e.g. using git) the needed the .yml files. The problem is a little more complicated than that and there are already strategies and tools to tackle this problem. Here are some of them.

1. Drush cim --partial

Drush help cim says: "Allows for partial config imports from the source directory. Only updates and new configs will be processed with this flag (missing configs will not be deleted)."
Meaning that you can only commit the files you need to transfer to a new environment (and e.g. put the ones you don't need to .gitignore) and you won't override or remove the missing settings which is default otherwise. This solves the problem not to override already mentioned running ID number configuration. The problem here is that if you have "old" config or the system does not realize that the configuration is updated (e.g. need to change something like translation file manually) this won't do the trick. See section 4.

2. Nimbus module

The module with config_split also uses config_filter[2] to separate configuration files to different folders and therefore "is a configuration management tool aimed at extending the configuration import functionality of Drupal core to support the import from multiple concurrent configuration directories for sophisticated configuration deployment workflows using dependency management tools." [3]

With Nimbus you can override configuration and only import the changes you need. The problem is that the import is also done using drush cex and the drush cim and won't solve the problem whether the import should be done using --partial or not. So it would reset the ID for example if the build is done manually.

3. config_split module

The tool which we are actually using now and is getting more popularity. It lets you predefine rules how the export should be done and magically splits the configuration depending on those rules which are called blacklisting and/or graylisting. Unfortunately we weren't using this tool in this project and I'm still not sure if it would have solve the problem. All I want to say here that check out the module [4] and test it's capabilities. It makes magic.

4. Manually using Drush

If you found yourself in a situation that you only need to transfer one configuration which is not new and is not defined as "update" by Drupal you have a challenge. Because drush cim would import all of the configuration (which we don't want because I only want the one specifig) and drush cim --partial won't do anything because there is nothing new (the .yml file was there and registered already) or updated. Only something has changed but counted as updated.

The solution here was found at the comments from drushcommands.com [5] which was to

  1. Create new folder ($ mkdir config/language/fi-new) and copy the configuration file there which you want to import ($ cp fi/some_address_id_creation_stuff.yml config/language/fi-new)
  2. Import all changes from that folder
    $ drush cim --partial --source=../config/staging/language/fi-new --preview=diff
    Here the flag --preview=diff is not needed but highly recommend every time you do imports manually.
  3. Remove the folder because this was a one time import. The original same file stays where it was.


Importing only one config should be possible to import using drupal console [6]. But like said there are different tools and deployment processes and we are not using drupal console - yet.

If you have better solution how to import only one config file or a tool to build perfectly working automated deployment process let me know.

[1] https://www.youtube.com/watch?v=57t_CS2wbHI&list
[2] https://www.drupal.org/project/config_filter
[3] https://www.drupal.org/project/nimbus
[4] https://www.drupal.org/project/config_split
[5] https://drushcommands.com/drush-8x/config/config-import/
[6] https://hechoendrupal.gitbooks.io/drupal-console/content/en/commands/config-import-single.html


CEO, Full stack Entwickler
Tipi Koivisto

Neuen Kommentar schreiben