How do I dynamically modify the configuration?

[leeqvip]

I tried to modify the configuration hostname, it doesn't work:

$config = config('Database');
// echo $config->default['hostname']; // 127.0.0.1
$config->default['hostname'] = '192.168.1.2';

Then in another place:

$config = config('Database');
// echo $config->default['hostname']; // 192.168.1.2

Database::connect('default');

It still uses 127.0.0.1 to connect ...

[MGatner]

I believe this is a duplicate request to #1661

[jim-parry]

It is similar to the one you mention, as well as #1618, but different ... wanting to change configuration settings at runtime, from the sound of it. It could be that addressing wither of the others in 4.1 might resolve this too.

[leeqvip]

Can we change new \Config\Database() to config('Database') ?
such as: system/Database/Config.php#L90

[lonnieezell]

@techoner changing that line is a good idea, I think. Care to submit a PR?

[leeqvip]

@lonnieezell Just submitted a PR, #2224

[lonnieezell]

@techoner Awesome. Thanks! Merged.

Does this fix this issue also?

[MGatner]

This brings up a good point, now that we have config($serviceName) that searches across namespaces in an appropriate order (App, System, third party) should internal config calls be using the function (or Config\get()) instead of the class directly to enable overriding/extending?

[MGatner]

... followup question, should the "appropriate order" be (App, third-party, System) to enable modules to override core configurations? Increases security concerns but also extension potential.

[lonnieezell]

@MGatner Yes, internally we should typically be using either the helper or Config\get() since that caches the results and helps keep things speedy. I a partial sweep through the framework when i created that functionality, but obviously was not an exhaustive one.

There might be occasions where we don't want to use that but I think 99% of the time it should use it.

[lonnieezell]

@MGatner as for "appropriate order" my decision on that order the first time put system above modules to ensure someone couldn't install a module they hadn't inspected very well and run into a situation where the modules' config overrode system settings without the app realizing it, potentially leading to bad results. Seems safer to this way.

If they want to use a config file that's named the same as one in the system, it should be a known step on the part of the developer to copy it from the module to the App/Config.

[leeqvip]

This fixes this issue.