After four years of development, I’m still a big CodeIgniter fan, although some other frameworks are starting to look mighty interesting.  Despite the bugs in Version 2.0.2, however, CI is heading in the right direction.

One CI-related issue that has caused problems for my workplace in the past has been the ability to setup distributed development environments.  Everybody has a different local setup, and some of the configuration directives inside of CI’s application/config folder must change from machine to machine.

Of course, we can’t just tell Mercurial to ignore that folder during commits, because there are some configuration directives that should remain the same across all environments, such as language, charset, enable_hooks, etc.

So, how to make some configuration settings consistent across different computers, and how to make some local settings?

Enter: config.local.php.

The solution is to create a local configuration file that overrides default config.php settings.  This way, local environments can set certain settings locally, and use the defaults in the application/config folder by default.  Here’s how to do it:

Step One: Create a local configuration file, and add certain configuration settings that you want to override.  You can put it in your root folder, and name it ./config.local.php For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
 
/* Local Configuration Options */
$config["base_url"] = "http://localhost/projects/my_project/";
$config["index_page"] = "index.php";
$config["uri_protocol"] = "AUTO";
$config["email_protocol"] = "sendmail";
$config["mailpath"] = "/usr/bin/sendmail";
$config["smtp_host"] = "";
$config["smtp_user"] = "";
$config["smtp_pass"] = "";
$config["smtp_port"] = "25";
$config["smtp_timeout"] = "5";
$config['log_threshold'] = 4;
//..and whatever else you want to override..
 
/* EOF */

Step Two: Set your version control system to ignore this file.  If you’re using Mercurial, simply add a line to the .hgignore file:

1

^config\.local\.php$

Step Three: Subclass the core/Config.php library to read the local configuration file after reading the default one every time.  To do this, create the file application/core/MY_Config.php in your application folder, and add the following code inside that file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');
 
class MY_Config extends CI_Config
{
	/**
	 * Load a config file - Overrides built-in CodeIgniter config file loader
	 * 
	 * @param string $file
	 * @param boolean $use_sections
	 * @param boolean $fail_gracefully 
	 */
	function load($file = '', $use_sections = FALSE, $fail_gracefully = FALSE)
	{
		parent::load($file, $use_sections, $fail_gracefully);
 
		//Local settings override permanent settings always.
		if (is_readable(FCPATH . 'system/config.local.php'))
			parent::load('system/config.local.php', $use_sections, $fail_gracefully);
	}
}
 
/* EOF: MY_Config */

Using local settings for database Configuration

Another file that is likely to be completely different from one environment to the next is the application/config/database.php file.  Since CodeIgniter seems to read the database settings a bit differently than normal settings, we have to go through one extra step to override those.  It’s a bit messier than I’d like, but gets the job done:

Step One: Add a line to your config.local.php for each database setting you want to override, but put the database settings in their own sub-array:

1
2
3
4
5
6
7

//...inside the local config file...
$config["db"]["hostname"] = "localhost";
$config["db"]["username"] = "localuser";
$config["db"]["password"] = "";
$config["db"]["database"] = "oeg_dev";
$config["db"]["db_debug"] = "TRUE";
$config["db"]["dbdriver"] = "mysql";

Step Two: Add the following code to the end of the application/config/database.php file to read those settings after reading the default settings:

1
2
3
4
5
6
7

//If there is a local config file, overwrite the settings with that..
if (is_readable(FCPATH . 'config.local.php'))
{
	include_once(FCPATH . 'config.local.php');
	foreach($db['default'] as $key => $val)
		$db['default'][$key] = (isset($config['db'][$key])) ? $config['db'][$key] : $val;
}

There you have it!  From now on, you can your local configuration file to override any configuration setting in CodeIgniter.  This makes sharing code a breeze.  You developers can set their own base_path, database, index_file and other settings that are likely to change from one environment to the next without modifying the main configuration files.

PS. Happy Friday!

PPS. Have a better method? I’d love to hear about it.

About a year ago, I wrote an article on this website about Version Control.  In that article, I touted the glory of Subversion, and mentioned:

“I’ve since tried other VCS systems like Mercurial, Git, and Bazaar, but have not found any compelling reason to switch.”

Well, I’ve since found my compelling reasons to switch.  SVN lost some of our files, and it was a pain to do all sorts of stuff (get setup, keep clean, branch, merge, etc).  I won’t get into; there are enough rants about Subversion on the ‘net already.  We use Mercurial now, and boy has our workflow improved.

Mercurial is my new favorite child, because it’s easy to setup, easy to use, easy to branch and merge, and easy to teach to my students.  Oh, and it just works.  Sometimes I think it runs off magic.

In order to help my colleagues make the transition from SVN to Hg, I came up with a few diagrams to explain the workflow.  I thought I’d share them here.

Mercurial Recipe for Success

You will Need:

1. Mercurial.  Grab and install it from the official site.
2. Your files.  You know, all of those css, html, and php files that you’ve been working so hard on.
3. A repository server.  If you don’t have one, go get a free account at Bitbucket.
4. A web server.  Install Mercurial here too.

The Workflow:

Setting up a Mercurial Repository

Day-to-Day Developer Workflow

Like most development n00bs, after I started using version control, I never looked back.  And neither should you.

It required me to change the whole way that my office operated, though.  See, the way that we were doing things before seemed so simple; we just edited files and shouted at each other if we collided in our editing.  As it turns out, this was a bad thing, and there have been better alternatives around way longer than I’ve even been in this business.

But like most crotchety, over-egotistical developer-types it took a while for me to come around.  Here’s a brief history of my flirtations and eventual commitment to version control.

Our Blissful, Youthful Ignorance

This wasn’t really that long ago…

1..2..3... Easy Peasy Japanesey.. and stupid.

We would all work directly on the files directly on our development server.  We would sit down, SSH into the server using our favorite editor and code away, never thinking of change management, reverting back to old versions, or who would be responsible for what.  Conflict resolution seemed easy… if I was editing a file named welcome.php, I would simply shout across the room, “Hey Mike–don’t work on welcome.php right now, or I’ll have to beat you!”.

Our revision control system consisted of me creating and storing weekly backups of the entire database and file system.  If we made a change that killed the system, we’d simply either lose that week’s work or spend hours debugging it.  It was all gloriously simple.

Version Control Puberty — The Angsty Years

One day, I decided to implement Subversion, mainly because other developers were sneering at me and telling me I was a dummy.  And while I didn’t want to be a dummy, the whole thing seemed overly complicated.  Why would I want to increase complication when everything was working so simple?  I also had some fundamental issues with this new version control idea:

• First off, everybody has to have to get their own copy of the entire file set.  Bad!  Doom! Insecure! I have to trust my developers with the codebase? ::Gasp::
• Secondly, what do you mean that developers can’t see their changes on the server immediately upon commit without some hacked hook system?  This means they’ll have to run LAMP on their local boxes, too!  Geez.. now we have to have local dev environment setup procedures, too..
• Finally, SVN requires management of its own.  You know.. backing up, securing access, and generally managing.  More overhead and more complication!

Grudgingly, in order to remove the “dummy” label from my operations, I implemented Subversion.  It was difficult at first to understand how it would fit easily into our procedures, but with some very helpful free online material, we started using it.

And sure, I did have to write procedures for setting up local dev environments AND install a subversion clients AND manage a repository server, but you know what?

All of that stuff was way worth it.

All Grown-up Now

Let me repeat that: whatever frustrations version control causes, they are all worth it.

After being SVN disciples for a while now, our development procedures have matured.  Here’s how we do things:

The way we do things now.. Much better!

I’ve since tried other VCS systems like Mercurial, Git, and Bazaar, but have not found any compelling reason to switch.   Either way, using version control has saved our sorry butts on more than one occasion and has made life easier in about 1,001 ways.

As a bonus, it has also forced us to use better procedures and generate better development documentation, which is amazing, because we’re pretty lazy.  Now if only we could find a tool to better force us to behave when it comes to unit testing…

Well, that’s my story.  If I’ve inspired you to use VCS, hooray!  Here’s a helpful place to get started.  If not, you’re a dummy.