0

I was a heavy Features module user in Drupal 7 so I'm trying to use Configuration Management in Drupal 8 to recreate my old workflow.

In Drupal 7, when I wanted to try making changes, I would:

  1. Add my current config to a feature (store the values of variables with Strongarm)
  2. Export the feature.
  3. Commit the code.
  4. Mess around with the variables and see if I like my changes better. If yes, update the feature. If no, revert the feature.

The key to this workflow was that I was storing the config in code on the same dev server that I was using; in other words, I wasn't syncing between two servers, but rather using the Features module to store a snapshot of a working configuration while I made changes that would potentially need to be reversed.

I see that I can use Configuration Management to export configuration, but this is in archive format, which isn't very easy to diff. Also, committing a bunch of archives to my git repository seems like the wrong way, and a big step backward from Drupal 7.

My question: In Drupal 8, is it possible to export configuration such that it can be committed to a git repo, then diffed and used as a "reset button" when making changes that go awry?

What I tried

In the Configuration Management documentation, it has the following solutions:

  • UI-based
  • Drush-based
  • File--system-based

But what I'm looking for is code-based. I thought this might be "file-system-based", but these files are in the /files directory, which is usually exempt from git by the .gitignore file.

Improve this question
2
  • a) you can export the whole config with Configuration module but it will be zipped, b) you can change the config storage from db to file just like it was in alpha version of Drupal.
    – user21641
    Commented Jan 28, 2016 at 13:19
  • I'm using Features for drupal 8 for my code-driven sites. My dev server with Features, export configs and turn it modules (add custom content, and other things via THEME_install or another hook), stag server just to make sure that is OK and in production server just install as a new module. Any changes just update module. So far, all good. This way you must run update.php for each module changes (that is automatically when you use extend window to update/install).
    – Vagner
    Commented Jan 28, 2016 at 13:20

1 Answer 1

Reset to default
2

I would suggest to only use features for reusable components between projects. The configuration management system works quite well for me for the workflow that you are suggesting.

To export all configuration to a directory (by default ./sites/default/config) 

$ drush config-export # or use the alias: drush cex

This exports your active configuration into a bazillion files, then you can add it to git as usual:

$ git add -A sites/default/config # -A includes deleted and new files
$ git commit -m "config: my config changes here"

Now you have your snapshot, you can play with your site and if you end up in a state that you are not happy with, you can always import your exported files back to the active configuration by

$ drush config-import # or the shorter: drush cim

You can also use drush config-diff name.of.config to see the differences. Or you could just export again and git diff them

If you like your new configuration better, you can just start again: export, commit, repeat.

This is also useful to push your configuration to your test server. You just need to deploy the new code with the exported configuration and import it with

$ drush @stagingsrv cim

For some advanced cases check out the config_devel module

Improve this answer
2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.