Problem/Motivation
Since #1833516: Add a new top-level global for settings.php - move things out of $conf / http://drupal.org/node/1882698 we should be using the new Settings API for low level and environment specific configuration.
Once this is complete then we can investigate whether or not these settings should actually live in a php file at all. This causes problems for other system's determining a Drupal instances configuration see #1954898: site-install fails to install over an existing site because the format of $config_directories in settings.php has changed for example of the problems this causes... preg_match on a php file to determine config directories sucks. For a related discussion see #1934152: FormBase::config() and ConfigFormBase::config() work entirely differently, may result in unexpected side effects.
The globals to convert are:
// Export these settings.php variables to the global namespace.
global $databases, $cookie_domain, $conf, $installed_profile, $db_prefix, $drupal_hash_salt, $is_https, $base_secure_url, $base_insecure_url, $config_directories;Remaining tasks
- #1951216: Replace global $databases with settings()->get('databases') (this issue also removes the complete unused
$db_prefix) - #1960344: Replace $is_https global with Request::isSecure()
- #2036259: Move $drupal_hash_salt to settings()
- ... more issues to be created