INI shouldn't be loaded from same directory as code

[NattyNarwhal]

Reasoning:

• If Toolkit is managed by a package manager, then it shouldn't put config in a library directory (confusing, hard to manage)
• Cases where there should be site-specific configuration (i.e an INI per site)
  • This could be done through say, an environment variable, or in code. The former seems preferable because then it wouldn't require code changes.

[alanseiden]

Thanks. I was thinking about this today while we taught a client how to turn off debug mode via toolkit.ini.

[NattyNarwhal]

proposed search order and names:

• Environment variable (call it like PHP_TOOLKIT_INI), so it can be overriden per-site if need be
• /QOpenSys/etc/php-toolkit.ini (for IBM i)
• /etc/php-toolkit.ini
• The Toolkit install dir (for compat)

Should it be overrriden in code too?

[NattyNarwhal]

realizing this could be from code too for i.e app specific

[alanseiden]

Toolkit install dir could contain a symlink to new location

[NattyNarwhal]

I will say that CONFIG_FILE is theoretically settable by defining it before Toolkit.php is loaded, but this seems greasy in a world where autoloaders exist. The fact the INI is basically handled by static resources sucks, and that could require a refactor to make instance-local.