[5.0] Config arrays incorrectly merged

[rikh42]

Steps.

1. Install a package with config
2. Publish the config to your app config.
3. When Laravel attempts to merge the config from the original package settings, with the settings found in your app, some elements are appended instead of being replaced.

Update: Looks like the same problem happens when merging environment specific config over the base config. Basically, config_merge() behaves very differently from array_merge() that was used before. The new behaviour does not appear to be correct

For example.
Config in package

return [
    'enabled' => [
        'first',
        'second'
    ]
]

Published (and edited) config from your apps config/packages/vendorname/packagename

return [
    'enabled' => [
        'alpha',
        'beta'
    ]
]

Expected array when you fetch 'enabled' from the config...

return [
    'enabled' => [
        'alpha',
        'beta'
    ]
]

Actual array you get when you fetch 'enabled' from the config

return [
    'enabled' => [
        'first',
        'second'
        'alpha',
        'beta'
    ]
]

Notice that the items in the 'enabled' array are appended. This appears to happen in config_merge() and differs from 4.2. It only effects config items that contain an array with a numeric index.

This was fine about a week ago. I think it relates to this commit...
5122ea0

I noticed this problem using the package rcrowe/twigbridge. It's extensions.php config file means you can no longer remove packages you don't want, only add additional packages to those declared in the default package config.

[v-jacob]

This is also happening when i'm using a local config that is suppose to override the production config. Instead of overriding, its merging the arrays. Also when merging, if the config array has keys that are numeric, the merged array will replace the numeric keys.

I'm using my login throttling configuration as an example
Ex. config/local/throttling.php

return [
    'throttle' => [
        'throttlingInterval' => 900,
        'thresholds' => [
            2 => 1,
            5 => 2,
            7 => 4,
        ],
    ],
];

Ex. config/throttling.php

return [
    'throttle' => [
        'throttlingInterval' => 900,
        'thresholds' => [
            10 => 1,
            20 => 2,
            30 => 4,
            40 => 8,
            50 => 16,
            60 => 32
        ],
    ],
];

The resulting merged array looks like this, which is what should not be returned
dd(Config::get('throttle.thresholds'));

array (size=9)
  0 => int 1
  1 => int 2
  2 => int 4
  3 => int 8
  4 => int 16
  5 => int 32
  6 => int 1
  7 => int 2
  8 => int 4

What should be returned is just the local config if I'm in local environment

[jasonlewis]

Yeah that looks like undesired behaviour to me. If you wanted to append you used to be able to use the append_config helper (which appears to still exist).

[simonhampel]

Yes, I agree that the new behaviour is not ideal.

If you have a configuration option with numerically indexed arrays, there is now no way to over-ride any default options using an environment-specific configuration, you can only ever append.

We need some mechanism for being able to choose between replacing numerically indexed arrays and appending to them.

[brunogaspar]

This #5531 is kinda related as well, i had this issue too on Laravel 4.2 when that PR was merged, but @taylorotwell reverted it, so it has back on Laravel 5 :c

[taylorotwell]

There is absolutely no way to satisfy everyone on this issue without having a more programatic Config builder like I tweeted one time but everyone lost their mind so we decided not to.

[brunogaspar]

@taylorotwell yeap i completely agree with you, it's impossible to please everyone.

I saw your tweet i believe, where you would basically do $config['foo'] = 'bar'; instead of returning the whole array, is that one?

[taylorotwell]

Correct, you would be able to do things like $config->push or $config->append even from a service provider or something.

[brunogaspar]

Yes, i liked that as well =P

I don't see anything wrong with that to be completely honest with you, it kinda makes things more flexible, but, it's me lol

[v-jacob]

a robust config builder sounds nice actually

[simonhampel]

While I do like the simplicity of the array-based configuration, I think these difficulties in relation to replacing vs appending configuration might be justification enough to consider an alternative.

I'd be interested in seeing how an alternative mechanism would operate.

[glennjacobs]

I too am having this issue on a number of packages. What's the correct way to override a config rather than append now?

[davzie]

Also interested in seeing how to override configuration items like this. This is a super deal breaker here for setting for example, a list of image sizes you want some images to be resized at (differently per environment) or a list of acceptable MIME types for a file upload. Merging them seems, just, the opposite of what currently occurs where I can be sure that as long as a configuration key is set, it will override the main configuration key. I'm not usually a complainy-pants, but unless there's a simple method for actually overriding here then I'm not sure how to approach solving this.

[phillipsharring]

I'll add that I'm in favor of a more robust config builder - $config->push or $config->append