Bug Report #4168

Loading order configuration files have changed

Added by Nas Dev 10 months ago. Updated 10 months ago.

Status:Closed Start date:08/01/2011
Priority:Normal Due date:
Assignee:Matt Button % Done:

0%
Category:Core
Target version:v3.2.1
Resolution:invalid Points:1

Description

We just upgraded from 3.1.3.1 to 3.2 and a number of our custom modules suddenly stopped working (after applying the upgrade changes) due to configuration issues.
It took us a while to figure out that the loading order of the configuration files stopped respecting the order that the modules are defined.

In 3.2 the loading order within modules is now the reverse of the order that the modules are defined. This is a breaking change.

For example, the default AUTH driver has been configured to be "file". Now we are unable to use orm as driver for our custom modules as our configuration files are first loaded and then the auth/config one. The only place it can now be overridden is in the application/config unless we define our child modules before the parent modules.

Basically the desired loading order would be system -> modules (in the order they are defined) -> application.

History

#1
Updated by Jeremy Bush 10 months ago

  • Status changed from New to Assigned
  • Assignee set to Matt Button
  • Priority changed from High to Normal
  • Target version set to v3.2.1

In 3.2 the loading order within modules is now the reverse of the order that the modules are defined. This is a breaking change.

For the record, breaking changes are allowed in major versions. That's the whole point of major versions.

However, this wouldn't be expected behavior.

#2
Updated by Matt Button 10 months ago

I'm confused as to how this is happening as the file reader has virtually no changes between 3.1 and 3.2 The module reversing itself is actually done by kohana core which to my knowledge hasn't changed between the releases

Please can you check that the incorrect config options that are being returned aren't being loaded from the db (just in case they've been accidentally copied over). Please can you also show us what config readers/modules you're initialising in your bootstrap. Finally, please could you also add a var_dump($paths); on line 649 of classes/kohana/core.php

#3
Updated by Nas Dev 10 months ago

Hi Matt,

We added debugging in both versions on many places only to discover that indeed there is no difference. In the end we found that our 3.1 branch had an auth configuration file in the application/config folder causing the difference. It seems that file was deleted in our 3.2 branch while upgrading causing the confusion. Sorry for wasting your time, you can close (or delete) this issue. We'll have to override the loading sequence ourselves somehow.

Kind regards

#4
Updated by Matt Button 10 months ago

  • Status changed from Assigned to Closed
  • Resolution set to invalid

No worries, glad to see I haven't screwed up everyone's applications!

Also available in: Atom PDF