Document how 'Overriding Configuration' is intended to work.

I think we can make things a bit clearer for users by updating the label.
Right now, "Clear overridden value" might leave some people unsure about what it actually does. I suggest changing it to "Clear overridden value from the configuration item." This way, it’s more specific and helps users understand exactly what will happen when they click it.

rajeshreeputra → closed merge request !50

rajeshreeputra → reopened merge request !50

Thanks!

But should $config = \Drupal::config('my_module.settings')->get('my_setting'); give me my setting value when this module is in place?

Or should I use $config = \Drupal::service('key.repository')->getKey('my_key')->getKeyValue();?

But should $config = \Drupal::config('my_module.settings')->get('my_setting'); give me my setting value when this module is in place?

This should not give the value, as value in config now cleared by the override.

Or should I use $config = \Drupal::service('key.repository')->getKey('my_key')->getKeyValue();?

This should give the value from the key.

Ok thanks!

So when I read

The Drupal 8 version of Key provides the ability to override any configuration value with a key. This allows site administrators to store configuration values in a more secure method than in the database or in settings.php.

• * Enter a name for the override
• * Select the specific configuration item you wish to override
• * Select an existing key that provides the value to be used; if the key doesn't exist, you'll need to create it
• * Check "Clear overridden value" to clear any existing value for the overridden configuration item; this is important to make sure potentially sensitive data is removed from the configuration; if for some reason, you don't want to clear the value, uncheck this field
• * Click "Save"

My expectation is that

$config = \Drupal::config('my_module.settings')->get('my_setting');

will still work, as above description does not mention anything about me having to alter my code and 'overriding' feels to me like 'taking over existing functionality without API changes'. So in my mind, the Key module would somehow intercept the 'get('my_setting')'-part, and return the value stored in the Key in stead of the emptied config.

What would be the exact use case of the current implementation? Why would I not just discard the whole config and replace it with Keys?

Sorry for the confusion caused by previous comment.

I would like to share a use case to clarify the expected behavior regarding configuration overrides with the Key module.

For example, let's say we have the following configuration:

my_module.settings:
  key1: value1
  secret: secret_value

• We override the secret value using the Key module.
• When we access the configuration value in code as:
  $config = \Drupal::config('my_module.settings')->get('secret'); the returned value should be the overridden secret from the Key module, i.e., secret_value from the key configuration.
• When we access the configuration value in CLI:
  ./vendor/bin/drush cget my_module.settings secret the returned value should be null.
• Even when accessing via configuration export it should be null, in my_module.settings.yml file.