Hi all,
For a while now, the skeleton has contained a directory,
config/autoload/*. The idea behind this directory to allow a very
simple place for people to drop in their own configuration overrides
for modules, or even drop in "dist" config files provided by modules
which provide a template of configurable settings/options for a
module. I'd say this directory has quite successfully served its
purpose thus far.
I want to re-visit a discussion we had in a meeting a couple of months
back about configuration overrides and environment-specific configs.
Please keep in mind that what I'm discussing is simply about what we
provide as a suggestion in the skeleton application. **This does NOT
affect any framework code.**
So, historically when we first added the config/autoload directory, we
had it set up to load config/autoload/*.config.php.
In our meeting on 12-07-2011, due to questions about
environment-specific configs, we decided to introduce the concept of
"global" and "local" configs. To accomplish this, we changed the glob
pattern to what it is presently:
config/autoload/{,*.}{global,local}.config.php. See
http://framework.zend.com/wiki/display/ZFDEV2/2011-12-07+Meeting+LogThe idea is that anything ending in ".local.config.php" will be merged
after anything named *.global.config.php, meaning config from "local"
configs takes precedence over "global" configs, allowing you to
override config with local config files in each specific environment
you may have (development, testing, production). As a detail, the
beginning *. is optional, so you can also just have local.config.php
and global.config.php without prefixes. However, this change broke
some BC because no longer will a filename like foobar.config.php be
matched by the glob pattern. It must end in either .local.config.php
or .global.config.php. An example of something this broke is in
ZfcUser, I have a dist config file named
module.zfcuser.config.php.dist, which I had been instructing people to
copy (sans the .dist) to their autoload directory and edit to override
configuration. Now we'd have to rename that to something like
module.zfcuser.global.config.php.dist. Not only is this getting pretty
long, I'm not really fond of pre-determining that the user wants the
settings in that file to be global, and it could cause some confusion
for beginners about what can/can't/should/shouldn't be overridden for
a module.
So with that explained, here's some thoughts and questions I had:
- I'd like to remove the ".config" part of the pattern as a
requirement, and make it optional. With these files being under a
config/ directory, I find having "config" in the filename a bit
redundant. You'll also notice in the meeting log linked above, there
was no mention of having config in the filenames. The fact that it
remains in the glob pattern is simply a leftover artifact of the
earlier implementation.
- Do we want to *require* the "local" and "global" parts in the
filename with the default glob pattern in the skeleton, or should
those just be optional? If they're optional, that would create three
"groups" of config files: global, local, and neither... The reason for
not simply doing *.php is that based on the current recommendation, we
want "local" configs to be merged before and take precedence over
global config files. By specifying the glob pattern in braces for the
two, we can dictate the order the files are returned by glob() in.
If we do want to require local or global, we could use a glob like
"config/autoload/{,*.}{global,local}.php" however it's not quite
right:
[0] => config/autoload/global.php
[1] => config/autoload/local.php
[2] => config/autoload/00-database.global.php
[3] => config/autoload/bbb.global.php
[4] => config/autoload/00-database.local.php
[5] => config/autoload/aaa.local.php
Something like "config/autoload/{global,*.global,local,*.local}.php"
gets us a little closer to what I'd expect:
[0] => config/autoload/global.php
[1] => config/autoload/00-database.global.php
[2] => config/autoload/bbb.global.php
[3] => config/autoload/local.php
[4] => config/autoload/00-database.local.php
[5] => config/autoload/aaa.local.php
(The local..php is intentional just to help illustrate how the glob is
matching.)
Making the global/local parts optional could prove a little more
tricky. We could do it with multiple globs or a complex glob but
there'd likely be overlap in the matches (one file matched multiple
times), so we might want to look into running array_unique(glob()) or
something along those lines.
- Should we promote (not enforce in any way) the use of numeric
prefixes for autoloaded config files? In the *nix world, this is a
common practice in conf.d/* situations where in /etc/X11/xorg.conf.d/,
you might find something like 00-system-setup-keyboard.conf
10-synaptics.conf. My argument for this is that it's very simple to
explain and document this concept for new users. This practice can be
used in conjunction with the global/local concept to allow for more
fine-grained control within groups.
Thanks,
--
Evan Coury
Locked
