Settings provided by other modules

As a general guideline, we can export to regular features only custom configuration that we have ourselves created, such as a view mode or a field. If we're configuring using a module-provided settings form, that configuration will already be provided by the module. A hint that this may be occurring is that the name of the configuration includes another module's name, such as realname.settings.yml. Another hint is if the configuration does not show up by default as available for adding to your feature (that is, you have to check the option to allow conflicts before it will show up).

There are two options for providing such configuration:

• The first is to add it to the install profile, which is allowed to override configuration provided by other modules. This option is appropriate if:
  • The configuration should always be active on all sites installed with the install profile; and
  • The configuration is not required by other configuration or functionality. This consideration is because the install profile is typically installed last and nothing should require the install profile.
• The alternative is to add it as via one of the various options for overriding configuration, such as the Config Actions module or Configuration Rewrite module.

For example, If you chose to use Config Actions, to change a configuration option provided by the Real Name module, you might add a file config/actions/realname.settings.yml with the following content:

path:
- pattern
plugin: change
actions:
'full name':
  value: '[user:field_user_first_name] [user:field_user_last_name]'

(where full name is an arbitrary key identifying the change) and then add a dependency on config_actions. See the Config Actions documentation for more detail.