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
Comments
Comment #0.0
alexpottUpdated issue summary.
Comment #0.1
alexpottUpdated issue summary.
Comment #0.2
tsphethean commentedUpdated issue summary.
Comment #0.3
ParisLiakos commentedAdd issue for $drupal_hash_salt
Comment #1
sunNot all of the global variables from settings.php are to be converted into
Settings, because theSettingssingleton is a read-only construct; i.e.,$settingsfrom settings.php are not supposed to be changed at runtime.A good example is #2176621: Remove global $databases
So I'm adjusting this meta issue title accordingly. But aside from that,
+1,000 — this is long overdue and really helps us to clean up some ugly code, especially in tests :)
Comment #2
Crell commentedThis doesn't need to be WSCCI.
Anything else here that remains to be done? Can someone update the summary with any remaining globals to kill, and/or mark this issue fixed?
Comment #3
alexpott#2183591: Replace global $config with a property on the Settings singleton
Comment #4
dawehnerLet's add the related issue for all the pager ones: #2229983: Remove globals on template_preprocess_pager
Comment #18
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #19
andypostCurrent globals are
and there's some usage which is related to #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole