MODULE/THEME DEFAULTS

Remember how variable defaults were used in Drupal 7?

$value = variable_get('my_variable_name', 'my_default_value');

In Drupal 8, you don’t need your setting defaults to be scattered throughout the code. If you have a setting, set its default value during the module installation. There are two ways to do that:

1. the easiest and the simplest way is to place YAML files with your defaults in the config/install directory (example from core Comment module)
2. the second option is for cases when the setting default value should be calculated dynamically on the module/theme installation, use hook_install() to do that

An examples can be found in the core Comment module. In the contact.form.feedback.yml file, the recipients setting is set to an empty array. Then, in contact_install(), actual value is set to the recipients.

EXPORTING CONFIGURATION INTO A MODULE

There is one interesting fact about the config/install directory.

In Drupal 7, we can export various functionalities in our module’s code. The common example is a View for a module administrative UI. For this we would need a basic knowledge of views API, some hooks, and a bit of copy-pasting. The Features module also could help with that task.

With Drupal 8 things getting easier. An example for a view:

1. build a view
2. export site configuration
3. find your view YAML file in the exported configuration (example: views.view.my_cool_view.yml)
4. put that file under the config/install directory of your module

Voilà! Your view will be imported automatically on the module installation.

CONFIGURATION OVERRIDE SYSTEM

One of the best things in Drupal is that we can alter (change) everything. Configuration is not an exception there.

There are two levels of configuration overrides.

Settings overrides

The settings.php file could contain environment level overrides. Just remember how we disabled email sending on development servers in Drupal 7:

$conf['mail_system']['default-system'] = 'DevelMailLog';

That’s how it will look in Drupal 8:

$config['system.mail']['interface']['default'] = 'devel_mail_log';

Module overrides

Dynamic configuration overrides could be implemented in modules. Overrides are provided by services tagged as config.factory.override implementing ConfigFactoryOverrideInterface. An example can be found in the core Language module which translates strings coming from configuration (so when you call Drupal::config(…)->get(…), you actually get translated strings instead of original ones).

Getting raw (not overridden) data

Sometimes we need to get initial, not overridden configuration. Generally, this is required for configuration forms (for instance, to allow the user edit original strings instead of their translations). And this case is handled right in Drupal core: all we need is to use the ConfigFormBase class instead of the FormBase for our forms, and use it’s build-in ConfigFormBase::config() method instead of Drupal::config(). This will give us the raw data.

Another way is to call the Config::getRawData() method. And for more complex workflows, you may check the ConfigFormBaseTrait::config() method implementation.

Best practice tip

When you work from a class extending some base class, be sure to check all built-in methods you have, and use them in the first place. The example above demonstrates how to get the raw configuration data using the ::config() method when working from the ConfigFormBase subclass. Another one example: many classes have built-in ::t() method that should be used instead of global t() function. There is always a reason for that, check out an example.