Score:3

Exclude settings from a contrib module on export

us flag

I've two environment, dev and staging. I'm using the ReCaptcha module.

In the developpement environment, I have some api keys a other config which until now, are exported thanks to drush cex inside the recaptcha.settings file

site_key: mysite_key
secret_key: mysite_secret
verify_hostname: false
use_globally: false
widget:
  theme: dark
  type: image
  size: ''
  tabindex: 0
  noscript: false
_core:
  default_config_hash: mydefault_hash
langcode: fr

If I update my staging files website, the config from the development is imported with drush cim.

How can I, without another module, prevent this ?

In my settings.local.dev.php, I've added this line and ran drush cex :

$settings['config_exclude_modules'] = ['recaptcha'];

And it gave me this result

enter image description here

The config is completly deleted, but I'd like to keep all the config but not the site_key / secret_key (such as theme etc...)

I wish I could have a config for the development and the staging separetly, but still using drush commands.

cn flag
You don't need to mess around with exports here, your secret key should never be in the codebase anyway. Use a [config override](https://www.drupal.org/docs/drupal-apis/configuration-api/configuration-override-system) in settings.php instead, much simpler
Score:4
cn flag

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.

mt.i.1 avatar
us flag
This is tricky, because my client will probably change the key one day or another (my question is more global than only one module in fact), so in this case, I don't think doing it by the code is the best approach... But if I end up by doing by the code, if I understand well, I have to add this `$config['recaptcha.settings']['site_key'] = "mycustomky";` inside *settings.local.dev.php* ?
cn flag
@mt.i.1 Yes, that looks correct.
mt.i.1 avatar
us flag
It's working well on front, is it possible to "link" key in the database so that it appears in the backend ? Those fields are required, and I can't submit the form to save the other settings
cn flag
@mt.i.1 You can use the production field value or a dummy field value (a bad API key that validates) to allow you to save the config.
hotwebmatter avatar
nr flag
If you don't want to save passwords and API keys in the active config (where they will be exported as YAML and exposed in the code repo in plaintext) or in a settings file (also exposed in the code repo as plaintext) you can store these values in a `secrets.php` file, unique per environment, which can be sourced by `settings.php` or `settings.local.php`.
mt.i.1 avatar
us flag
Yes, I've endend up by doing something like that !
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.