While the subject might sound dark and scary the reality is the Solar Frameworks config system is one of the things that I truly enjoy about Solar 99% of the time.

Its that other 1% you need to be aware of to keep yourself out of the rabbit hole.

Everything you put in Solar.config.php is nicely mapped to the proper classes and easily available in the class through the $this->_config property. Sounds extremely simple right? It is simple but at the same time presents some problems that if you do not consider from the start can lead you down a very twisted path!

First in complicated systems you may have some config items that have very broad effects across your whole system however default values put within a class are not "always" accessible outside the class itself through the Solar_Config and you might be tempted to use the following code in other classes

But be aware if the Solar_Example class has not been loaded you will not have any default values from that class included, ONLY values found in your Solar.config.php file. This in itself if you are not aware can cause you countless hours of frustration.

Second, you will run into items you need to have more configurable so you put them in the DB so you make a nice model and start pulling some config from the DB but as a project gets larger the intermix of Solar.config.php and DB based config can get confusing. Do all new items go into the DB? Do only items you feel might need to be changed often?

Third, how do you handle Production vs QA vs Dev vs Staging, some things need to be disabled or enabled depending on the environment your running on..

All three of these things can cause you to trip down a deep hole later on in development but if you are aware of them from the beginning and plan for them you can jump over the rabbit hole and keep on moving.

We will cover extending Solar to inject config from a DB at a later time.