Add a default parameter to the config get() method

Why is this needed?

Reopening for the discussion of how to handle defaults for config, on the assumption that defaults for state will be passed as a second parameter.

At the moment, defaults are often set using :?

\Drupal::config('my_settings')->get('some_key') ?: 'default value';

This will creates confusion for developers between state and config, as they will use different methods

\Drupal::config('my_settings')->get('some_key') ?: 'default value'; // correct
\Drupal::state()->get('some_key', 'default value');                         // correct
\Drupal::config('my_settings')->get('some_key', 'default value');   // No default supplied - will default to null

I believe this is also an unintentional change from variable_get in 7.x which fell back to the default using isset(). The PHP ternary operator uses empty(), which means you can't have a boolean default to TRUE.

\Drupal::config('my_settings')->get('some_key') ?: TRUE; // Will return TRUE whatever 'some_key' is set to.

Both of these could be fixed by enforcing schemas that supplied defaults (so defaults would never be set inline), but I don't think that's currently the plan.

Let's use real examples, because none of those are legitimate.

1. core/modules/block/lib/Drupal/block/Tests/BlockTest.php
   181:    $default_theme = \Drupal::config('system.theme')->get('default') ?: 'stark';
   

2. core/modules/color/color.module
   135:  return \Drupal::config('color.' . $theme)->get('palette') ?: $palette;
   

3. core/modules/menu/lib/Drupal/menu/Tests/MenuTest.php
   397:    $default_theme = \Drupal::config('system.theme')->get('default') ?: 'stark';
   

4. core/modules/node/node.module
   705:  $submitted = \Drupal::config('node.type.' . $node->bundle())->get('settings.node.submitted') ?: TRUE;
   

5. core/modules/system/system.install
   1945:  $front_page = \Drupal::config('system.site')->get('page.front') ?: 'node';
   

6. core/modules/system/system.module
   225:      'description' => \Drupal::config('system.theme')->get('admin') ?: t('This is only used when the site is configured to use a separate administration theme on the <a href="@appearance-url">Appearance</a> page.', array('@appearance-url' => url('admin/appearance'))),
   

7. core/modules/user/user.module
   421:    $role_permissions[$rid] = \Drupal::config("user.role.$rid")->get('permissions') ?: array();
   

Those are all of the places we use a ternary with config().

1) This is a test, and a lazy one at that.
2) This already has a @todo to remove it
3) This is also a test
4) This is a bug, being fixed in #2053461: Node type settings such as published state, promoted state, create revision and author information cannot be turned off
5) This is in system_update_8046() for enabling the views module :)
6) This is cheating, it is casting TRUE to an empty string for the description
7) This is only used during updating (in maintenance mode!)

Every time you call config you should be sure that it exists already. Defaults must be provided. Anywhere we need this pattern, or would need a default parameter, is a bug or a hack.

What is said in #9 is correct doing this would be a massive step backwards for CMI.

Agreed. The confusion came because there are still places where defaults are supplied inline, and the documentation is not currently clear enough about how the configuration system should be used, particularly when the config key will be dynamic (e.g. adding additional configuration per-content type). I plan to improve the docs after I've learnt how it all works through #2102521: Finish converting menu.module to CMI

And lets get rid of 3 of those ternaries see #2112233: Remove unnecessary ternaries in around config()->get()