Now that Drupal 8 supports YAML, it would make sense to use it for the database configuration settings, and other options in settings.php (commented here).
This is horrendous:
$databases['default']['default'] = array (
'database' => 'database_name',
'username' => 'user',
'password' => 'pass',
'host' => 'localhost',
'port' => '3306',
'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
'driver' => 'mysql',
'prefix' => 'drupal_',
);
YAML is clear:
databases:
database: database_name
username: user
password: pass
host: localhost
port: 3306
namespace: Drupal\\Core\\Database\\Driver\\mysql
driver: mysql
prefix: drupal_
Comments
Comment #1
iantresman commentedComment #7
sluceroThis is a common solution in other systems, and would be familiar to many users dependent on local environment setups like DrupalVM that already leverage overall configuration in a YAML structure. I think the readability of it would be a big win, but the trade-off that would have to be accounted for here would be the dynamic environment-checking and other conditionals that often end up in the settings.php file as well.
We already have the services.yml file that follows a similar format to this, so maybe a parallel to that for some of these settings even if settings.php just includes a line to parse the settings.yml file separately?
Comment #8
gordon commentedYes this would be great idea to move the majority of the basic settings eg. $foo='bar' to yaml.
However this will not get rid of the settings.php file but will make it optional, or an empty php file.
99% of what is in normal sites settings.php is just assigning variables, however when using modules like memcache there is a chunk of php that needs to be added so that the caching will work correctly. Not to mention hosting such as Acquia which uses the settings.php to determine which environment is there and setup Drupal correctly.
Comment #9
sluceroI agree there's a lot of utility in having PHP available in some cases for handling settings. Often the most common use case for this, in my experience at least, is for conditionals driving environment-specific settings or config overrides. Much of this could be delegated to specific include files, whether that's additional YAML-based settings files to include if available or PHP settings files more akin to our current iteration.
I propose that as part of the transition to using YAML for the majority of the settings file, an additional
includeskey could be added that:Using this format, items that have to be conditionally included could still be contained in a PHP file with the appropriate conditional wrappers, but other items could be delegated out to more focused YAML files for configuration and inclusion in appropriate environments.
Comment #21
quietone commentedThank you for the idea!
The proposal doesn't met the Criteria for evaluating proposed changes. In this case, there is not demonstrated demand and support for the change.
If there is interest in this re-open the issue and add a comment. Or open a new issue and reference this one.