A Weblog written, styled and hacked by Joel Moss
Something that I have been taking advantage of in my Cake 1.2 apps for quite a while now, is the ability to separate your custom config options from your app’s core.php file. And I am pretty sure that it is one of those lesser know features in 1.2.
The core.php file within your app’s config directory is used to store application wide configuration variables. Things like your debug level, cache settings and sessions store are set here using Cake’s very useful Configure class. This file can start to get quite large and unruly as the development of your app progresses. So one of the first things I do when I start a new app, is to separate my custom application config variable into another file within the config directory. This then keeps the core Cake configure settings separate from your custom ones, and keeps things a little dry.
Just create a new file in your app/config directory. You can name this anything you want, but I usually go with something like ‘config.php’ or ‘app.php’. As long as it ends with ‘.php’, it doesn’t matter.
Then in your app/config/core.php file, add the following line to the top of the file:
Configure::load('config');
As long as you pass the name of your newly created file, then it will be fine. So the above will work if I created a file called app/config/config.php.
Then within your new config file, you can set any config variables you wish. However, you don’t use the familar Configure::write('name', 'value'); convention. The variables that you set within your custom config file should be specified using arrays. Like this:
$config['name'] = ‘value’;
All variables in this file only, should set within the $config array as array name/value pairs. If your custom config file is called ‘app.php’, then the array name would be $app. So effectively, you could create as many of these custom config files as you wish. Perhaps if you had distinct sections of the app. I usually just create one, so I can easily access my custom config vars, without worrying about Cake’s built in config vars.
You access these custom config variables in the exact same way as you would any of the other built in core config vars.
Configure::read('name');
Enjoy!
My name is Joel Moss, a web developer and all round nice guy, living in Manchester, England. I am currently working full time for ShermansTravel.com, but I fill whatever spare time I have with lots of good and wholesome "stuff"! Like developing my own ideas; such as Tooum, contributing to the excellent CakePHP framework, and doing more work for ShermansTravel.
So this is my blog - my soap box! Here I attempt to share my likes, my dislikes, and my opinions. As well as providing some occasional respite from the daily crap we all endure. Enjoy ;)
Hey, if you want to reach me, i'm available via email:joel[at]developwithstyle[dot]com, and AIM:joelkmoss.
Ben Rasmusen
November 5th, 2008 at 2:06 pm
We recently discovered the custom config.php file in a project I’m working on and it’s definitely come in handy.
We however use the Configure::write(’name’, ‘value’); method of storing variables in the custom config.php file. And to access them in the controller, for example, we use: Configure::read(’name’); which seems to work fine.
What’s the advantage of using the $config array? Is it always accessible without doing a read? Performance?
Thanks for the great post!
Joel
November 5th, 2008 at 2:46 pm
Actually, I was always under the impression that Configure::write() couldn’t be used within a loaded config file. But seems I’m wrong.
I suppose the main advantage to this method is less key strokes. You still read the variable in the exact same way
Configure::read('name');LoudBaking
November 5th, 2008 at 3:04 pm
Hmm, isn’t bootstrap exactly for that kind of use?
Daniel Hofstetter
November 5th, 2008 at 5:51 pm
I would load the custom config file from bootstrap.php. core.php is a config file and so it shouldn’t do things like loading other config files.
Joel
November 5th, 2008 at 11:13 pm
@LoudBaking The bootstrap file can be used for absolutely anything. I tend to use it for custom functions that don’t belong in a class. So it’s nice to have a file only for vars.
@Daniel That is certainly another option, and perfectly valid I would have thought. I add it to core.php, because it feels like a natural extension of the core config vars.
thx for your comments guys
Neil Crookes
November 5th, 2008 at 11:18 pm
I too load my app/config/config.php file in app/config/bootstrap.php.
My config.php array stores static config settings for the specific application.
After loading it in bootstrap I then Configure::write() additional runtime specific configuration settings such as:
* invoked:(commandline|browser)
* environment:(dev|staging|live)
* os:(windows|*nix)
* site_or_admin:(site|admin)
…depending on a few conditionals.
It really helps define these runtime settings up front as I regularly test for them in applications to determine a certain branch of code.
Skylar Woodward
November 10th, 2008 at 5:10 am
Great post,
I just noticed this early last week while digging through configure.php. I thought it was a bit weird that you had to define a $config array, but I suppose part of the goal in that design is discourage code in this file and to encourage simple definitions. However, the only real restriction seems to be the file throws an error if you don’t define a $config variable - defining $config=array(); you can do whatever else you’d want here, much like an extension to bootstrap.php. As an encouraged convention, however, I like it (I think.)
Like the others I put the Configure::load in bootstrap.php to the point of keeping core.php as dry as possible.
One handy addition I made was to define several configuration arrays in config/config.php (i call mine config/local.php). Then, at the end of the file I choose which config array I want ($development, $production,…) and assign that to $config. This lets me easily preserve various development environments as I was used to in Rails.
Rob Wilkerson
March 30th, 2009 at 11:44 am
I am, admittedly, new to CakePHP in the last few months so maybe I’m not thinking about this correctly, but I’m not seeing what this separation buys you.
It’s no more DRY - provided you’re not repeating yourself in your config file(s). I can see an argument for encapsulation or, more accurately, segregation, but I still don’t see any advantage. I just put all of my custom settings at the bottom of core.php and achieve segregation that way.
Am I missing something? As a relative newcomer, is there some nuance that I’m failing to grasp that would make this kind of segregation more useful/beneficial that I can see right now? Or is it simply a best practice that I didn’t know about?
Thanks.
Joel
March 30th, 2009 at 1:43 pm
The whole point is separation. Keeping your custom configuration in a different file to your core configuration is a good thing. And means its more easily accessible.
At the end of the day, this one is all about personal preference.