Order of loading config and constants

When CI first loads the config.php file, it first grabs the one located at

    /application/config/config.php

and then it loads the one located at

    /application/config/ENVIRONMENT/config.php

But when loading constants.php, it does it in the reverse order:

    /application/config/ENVIRONMENT/constants.php

and then

    /application/config/constants.php

Is there any reason for the change in different order? I would like to load a global constant in /application/config/constants.php that is referenced in the ENVIRONMENT/constants.php file, but they load in a backwards order.

I see the order for config.php referenced at https://www.codeigniter.com/user_guide/l...vironments but nothing about the order for constants.php

Is this arbitrary? Any chance it could be changed in future releases?

If I had to guess (and I do) the order is probably done that way because the defines in config/constants.php should NOT be changed. For the most part those constants correlate directly to values expected by PHP functions. Changing those values could have very bad consequences.

That said, I did a search through the core files for usage of config/constants.php constants. While I didn't search for all of them, the ones I did look for are for the most part not used anywhere. The one that is used (SHOW_DEBUG_BACKTRACE) is found in some error views. However, any of them might be used by a third-party package that relies on the defined values.

That they are mostly unused by the core suggests they exist for the convenience of developers. Or, maybe they are the vestigial remains from earlier versions?

If I had to guess (and I do) the order is probably done that way because the defines in config/constants.php should NOT be changed. For the most part those constants correlate directly to values expected by PHP functions. Changing those values could have very bad consequences.

I use config/constants.php and config/ENVIRONMENT/constants.php to set my own application-wide and installation-specific constants respectively. I'm not concerned about the defaults in those files.

It would be nice if I could set default constants for the site in config/constants.php AND THEN set the environment-specific constants in config/ENVIRONMENT/constants.php, but the order is reversed.

So my question really is this: is there a reason for the order they are loaded? Could that order be changed in future versions of CI?

What difference does it make? All the constants in both files will be defined either way. The config/constants.php are loaded first to prevent attempted redefinition in ENVIRONMENT/constants.php for the reasons I stated earlier.

If for some reason you need a constant from config/constants.php for use in ENVIRONMENT/constants.php that could be accomplished by putting this at the top of ENVIRONMENT/constants.php

PHP Code:

if (file_exists(APPPATH.'config/constants.php'))
{
     require_once(APPPATH.'config/constants.php');
} 


Then when Codeigniter.php runs that same block nothing will change because all those constants are already defined.

What difference does it make? All the constants in both files will be defined either way.

I makes a difference because I can define any defaults in the primary constants file that may have not been defined in the environment constants file.

For example suppose I want to say in config/ENVIRONMENT/constants.php:

PHP Code:

define('EMAIL', '[email protected]'); 


Then in config/constants.php I can say:

PHP Code:

defined('EMAIL') OR define('EMAIL', '[email protected]'); 


That way, if an environment doesn't have it defined, I can have a fallback default. The way it works now, if I define the defaults in the global constants file, I can't redefine then in the environment-specific constants file.

But all the same, your proposed solution cuts through all of that! Simple and easy, thank you. It's a bit of a kludge, but it works which is what I'm after.

If you define defaults in config/constants.php and it is loaded before config/ENVIRONMENT/constants.php, then you'd always have the defaults ... Constants aren't variables, you can't redefine them.
In order to get the cascading effect that you want, it has to work like it currently does (higher precedence first).

But on a more important side-note - reliance on constants is a design flaw in 99% of the cases; you probably don't need them at all. I can't even remember the last time I declared a global constant.