You don't need to exclude the API keys from export; instead, you can set them in code, and then it doesn't matter what gets exported. (...probably. Some modules will not work with this approach.)
You can override config directly in settings.php
.
Here's an example with Swiftmailer module taken from one of my sites.
swiftmailer.transport.yml
transport: smtp
smtp_host: smtp.example.com
smtp_port: 465
smtp_encryption: ssl
smtp_credential_provider: swiftmailer
smtp_credentials:
swiftmailer:
username: ''
password: ''
sendmail_path: /usr/sbin/sendmail
sendmail_mode: bs
spool_directory: ''
_core:
default_config_hash: RSNbRD3ekSaZoE19f3eHhm93gKOcD2PtmaAVmV3XMes
langcode: ja
Now I want to use a different API key for dev + production. So, in settings.php
, I set the config manually:
$config['swiftmailer.transport']['smtp_credentials']['swiftmailer']['username'] = 'apikey';
$config['swiftmailer.transport']['smtp_credentials']['swiftmailer']['password'] = 'ABCDEFGHIJKLMNOP'
In my case I'm using a switch to detect an environment variable (live, test, dev, etc.) because that's how the host Pantheon does it, but you can do the same thing with settings.local.dev.php
files.
Config in settings.php
will never be exported; drush will ignore it. However, Drupal will always prioritize config set in code over .yml
files. As a result, if you need to change this, you will have to update the code itself; you won't be able to make changes from the UI anymore.
Also note that it is a potential security issue to check API keys into version control like this.
The Config Override module adds a warning to admin screens that reminds you that you are overriding values in code.
If security is a concern, there's the Lockr module, which was built specifically to handle the use case of juggling API keys, but you have to pay for that.