17

I thought this was a simple use case of the new Configuration management system, but I haven't had any luck finding out how to solve this:

Problem

I want to store configuration in git and use drush to export configuration during development and then on deployment import the configuration. Pretty similar to doing a features revert in Drupal 7. My problem is that I don't want to store access codes in git for various integrations. This results in these configurations being deleted on
$ drush cim -y

Where I looked

I was hoping there would be a simple list/configuration for configs that should be excluded on import/export. It seems there was at some point but it must have been removed again, since it's available at present Drupal 8 release.

I looked into how config changes are being made comparing the active and sync storange to see if there as a place where I could remove changes, this didn't seem to be the case. I looked at how drush does the configuration import as it has some configuration excludes of it's own, but it didn't look like this was extensible. I looked at ConfigEvents, but these all seem to happen after an import, so doesn't look like this can be used.

Am I missing something, or is it not possible to simply exclude configs from import/export?

7

It's not possible to have excludes specifically, but there is something.

Just like $conf in Drupal 7, there's $config in settings.php that you can use to override anything in configuration locally. The format is $config['name.of.config']['nested']['key'].

Note that whatever is stored in configuration is still in git, so you either need to keep none or your testing access codes in git. Also, the UI will show what's actually stored in config and will currently not provide any indication that it is overridden. There are pending issues to improve that.

I understand that this has limitations but right now, it's not possible to keep something out of the exported configuration. As far as I know.

  • So basically, you have to set / update configuration in your settings.php file instead of using the interface. – googletorp Jan 2 '16 at 13:33
  • Yes, this is nothing new. Nothing has changed in the workflow in this context in d8. – user21641 Jan 2 '16 at 14:05
10

You can use the "Config Ignore" module: https://www.drupal.org/project/config_ignore

Ever experienced that your site's configuration was overridden by the configuration on the filesystem, when doing a drush cim?

Not anymore!

This module is a tool to let you keep the configuration you want, in place.

  • 1
    config_ignore is probably the most stable and simple solution currently available, and this solution probably best addresses the OP's desire to have "a simple list/configuration for configs that should be excluded on import/export" – bdanin Mar 14 '17 at 18:01
  • 1
    But beware, currently it only supports config updates: "Configuration marked for deletion or creation will still be deleted or created.". But they are working on it: drupal.org/node/2857985 – Philipp Michael Mar 30 '17 at 13:40
6

You can use a combination of config_ignore and config_split for this.

Config ignore allows you to ignore a subset of configuration entities during import (also prevents deletes since the 2.x release). Unfortunately it doesn't prevent excluding config during export.

To exclude configuration entities during export, you can use config_split, create a new config_split entity, and leave the folder empty. This prevents the configuration from being exported to the file system; instead, it exports it in the database.

I wrote Exclude config from configuration management in Drupal 8 about this topic.

5

In order to split configurations you can use https://www.drupal.org/project/config_split.

Enter config_split that provides a Drupal console command for importing and exporting filtered configuration. Drush integration is likely to follow soon (after all the filter is inspired by the --skip-modules filter of drush).

You can split exports into different dirs which you can then git ignore.

There was a very nice presentation in drupal con dublin 2016 by the people in charge of the CMI initiative which I urge you to check out no matter what.

2

I just tested @berdir in #1 answer and it run perfectly. Only I add a little note: you have to put whole config in this var, complete. Wihtout it, $config var not run correctly.

Something like this:

 $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

Note from above documentation: "Note that values overrided via $config within settings.php will not be viewable from the Drupal administration interface."

  • 3
    You should not have to do this. It should merge in any values you define, but maybe it doesn't work as expected with some structures. – Berdir Feb 27 '16 at 14:36
  • Oh, I couldn't make to run it correctly. I will try to debug it again and if not run correctly maybe I can open a bug in d.org. Thanks! – estoyausente Mar 1 '16 at 10:34
  • 1
    I can confirm that you can do something like $config['module.settings']['some']['value'] = 'foo'; – googletorp Aug 9 '16 at 8:40
1

I somewhat wonder why nobody mentioned Drush CMI tools by now. The magic words are drush cexy and config-ignore.yml. You'll have a list you can adjust. We needed it once to have block instances excluded while at the same time the block bases got processed.

We want to export all configuration, but we want to exclude certain patterns.

This is where the --ignore-list option of drush cexy comes in.

In our project we have a ./drush folder, so we stick a file in their called config-ignore.yml with contents as follows.

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

So now we run drush cexy like so

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

So what this does is export the active configuration, and then apply the ignore list to remove unwanted configuration.

So now when you run git status you should only see changes you want to commit.

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

1

Using config split (recommanded)

The config split module was made specifically for this need.

Config split is integrated with drush.

Using Drush only

Drush it's also supposed to be able to do that by using the --skip-modules flag.

You can add the following lines in a drupal/drushrc.php in the webroot of your project to do it automatically.

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

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

Sadly there is a bug with this functionality: https://github.com/drush-ops/drush/issues/1820. So for the moment you also need to add those config files in your .gitignore so exported config files don't get committed. Their is an ongoing to perhaps abandon this (buggy) functionality from drush in favor of config split.

  • 2
    Ignoring the config files in git doesn't exactly work. Configuration not exported will get deleted. For example, custom panels pages will be deleted upon importing config. – dobrzyns Sep 15 '16 at 17:57
  • @user157272 even if you import using drush with ['config-import']['skip-modules']? – gagarine Sep 23 '16 at 11:06
  • drushrc.php can even be placed outside webroot. For example one level higher, which is useful when you work with Drupal in a composer setup: github.com/drupal-composer/drupal-project. – leymannx Oct 12 '16 at 12:48
  • This didn't work for me. I added modules, yet they were still added to the enable/disable modules config. – Jeremy John Jun 28 '17 at 16:06
  • I updated the answer with the current best practice (config split) – gagarine Jun 30 '17 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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