ZF-9391: Zend_Application 'config' option does not work properly if a string (path to the file) is passed

Description

There is currently support for 'config' option that may be either an array or a file path string. It is used to override current options. It may be very useful to use some local configurations, like having configs/application.local.ini for some specific machine related options.

If it is an array it works good but if it is a file it does not because it merges first, original options to the second (so the origin options override the local ones). Please, somebody change


$options = $this->mergeOptions($this->_loadConfig($options['config']), $options);

to


$options = $this->mergeOptions($options, $this->_loadConfig($options['config']));

in /Zend/Application.php line 134 (1.10.2 release)

I see some refactoring being done there, so it's probably a new issue. Probably since 1.10

Comments

Since there is no any response here for about a month (though new 10.3 just came out recently) I've decided to prepare patch/test for this issue to have it fixed faster, probably. And I found out why this was changed: http://framework.zend.com/issues/browse/ZF-6811

I.e. there is a BC break since 1.10 to be able to "overwrite ini data via the constructor call " like:


$app = new Zend_Application(
    APPLICATION_ENV,
    array(
        'bootstrap' => array(
            'class' => 'XmlRpc_Bootstrap',
            'path'  => 'path/to/Bootstrap.php',
        ),
        'config' => APPLICATION_PATH . '/configs/application.ini',
    ),
);

this way 'config' option becomes the real config path, not the additional one. Probably in some cases it is comfortable to do this thing via constructor call but it's not just logical imho so I would vote it to be changed back . Currently an option of the config becomes the config itself - it isn't that obvious is it? If it's a really common use case with that constructor thing I would suggest to add another parameter to the Zend_Application constructor which would contain options to overwrite the main config.

I'll change it to an improvement issue though.

Another little thing if somebody cares in the documentation here http://framework.zend.com/manual/en/… it's said:

{quote} As of 1.10, you may also pass multiple paths containing config files to be merged into a single configuration. This assists in reducing config duplication across many contexts which share common settings (e.g. configs for HTTP, or CLI, each sharing some characteristics but with their own conflicting values for others) or merely splitting a long configuration across many smaller categorised files. The parameter in this case is an array with a single key "configs" whose value is an array of the files to merge. Note: this means you either pass a literal path, or array("configs"=>array("/path1","/path2"[,...])) {quote}

'configs' is wrong and causes an error. Should be just 'config'.

This was evidently changed on purpose (See quote from ZF-10945):

Lead developers stated the following: "It was never really intended. The reason we have it at all was because of a particular use case where developers wanted to provide some defaults via the initial Zend_Application initialization, but still utilize a config file We never intended to allow nesting of configs, to be honest – that's something I'm hoping we can build into Zend_Config for ZF2 (instead of emulating within Zend_Application)."

It's been in ZF since 1.10, so reverting the change would itself be introducing a backwards-compatibility break, and i'm not sure how we could accommodate both