Archive for the ‘CodeIgniter’ Category

PHPDbMigrate & CodeIgniter

August 18th, 2009 by ScottK | No Comments | Filed in CodeIgniter, PHP, PHPDbMigrate

As a single developer on a single application running different environmentsспални комплекти I find it tedious to have to duplicate my database changes everytime, whether they are permanent or not. When working with a group of developers and all of use making changes to the database schema it becomes even more hectic as to what was changed.

Since I am writing PHPDbMigrate as a PHP database migration manager and since ateI’m working with CodeIgniter almost exslusively I decided to incorporate PHPDbMigrate as a way for me to manage the applications database schema into CodeIgniter.

Now as I make the needed schema changes I only have to do it in a migration file. From which I can easily update all my environment databases. Along with that the other developers can easily see what I have changes, and I can likewise see their changes. Additionally PHPDbMigrate supports code blocks for running native PHP code in the migration for added help!

In the event we need to roll back those changes we have the option to do so to specific versions. This is an extremely important aspect to a failed production deploy where the code needs to be reverted as well as the database.

Installation is fairly straight forward. Choose the tar or the zip type downloads below and extract into your application. I have a README in the root folder to explain the rest on the install.

Currently PHPDbMigrate only supports Mysql(i). I’m bringing on more database types soon.

PHPDbMigrate-CodeIgniter zip file

PHPDbMigrate-CodeIgniter tar file

Tags: , ,

Setting up Environments in CodeIgniter

May 20th, 2009 by ScottK | No Comments | Filed in CodeIgniter

I will profess that I only a month old in CodeIgniter, a framework written in PHP, I’m certainly no stranger to MVC frameworks. My work with CodeIgniter has been download the clients site, do the work and upload to clients site. Unfortunately this also means reconfiguring the app for my dev box, then hopefully remembering to change those back before I deploy.

God forbid I forget the database change configs. >.<

So with that said I’m introducing how to set up running environments with CodeIgniter so you can work in development settings and then deploy to staging, or any other you specify, without needing to change configurations. Plus you get the advantage of having the ability to modify behavior in your app based upon environment.

Note: I hacking the core of any app, but one file must be changed, but it’s the heart and soul. So in the root index.php file I’ve added: just before the final

/*
|—————————————————————
| LOAD THE FRONT CONTROLLER
|—————————————————————

raman amplifier$http_host = str_replace("www.", "", $_SERVER['HTTP_HOST']);
$environments = array("development" => "localhost",
                      "production" => "techraving.com"
                     );
$found = false;
foreach ($environments as $k=>$v) {
    if (!$found) {
        if ($http_host == $v) {
            define("MY_ENV", $k);
            $found = true;
        }
    }
}

if (!$found) {
    define("MY_ENV","development");
}

So that the heart of setting up the environment. It’s detecting the host on which you are running on and defines the MY_ENV variable for use throughout the application. It’s he only hack to the core, I promise.

The next change would be to add an entry to the CodeIgniter autoload.php. You need to add the environments.php file the autload config section… or:

$autoload['config'] = array('environments');

Now create the environments.php file in the config directory as well as an environments folder. In the environments.php add this:

<?php
include_once("environments/" .  MY_ENV . ".php");
?>

In the environments folder you need to create the different files for each environment you specify in the index.php. So in my case I have to set up a “development.php” and “production.php” file. You can certianly add different files as your $environment specifies.

So what do you do with the different environments? Well here’s what I’m doing:

environments/production.php

<?php
$config['base_url']    = "http://www.techraving.com/";
$config['log_threshold'] = 1;
error_reporting(0);
$config['cookie_domain']    = "techraving.com";
?>

and in the environments/development.php

<?php
$config['base_url']    = "http://localhost/";
$config['log_threshold'] = 4;
error_reporting(E_ALL);
$config['cookie_domain']    = "localhost";
?>

So when I’m developing locally I don’t have to change any configs when I deploy!

What else is there? Well let’s look at the database issue in the config/database.php

$active_group = MY_ENV;
$active_record = TRUE;

$db['production']['hostname'] = "localhost";
$db['production']['username'] = "";
$db['production']['password'] = "";
$db['production']['database'] = "";
$db['production']['dbdriver'] = "mysql";
$db['production']['dbprefix'] = "";
$db['production']['pconnect'] = TRUE;
$db['production']['db_debug'] = TRUE;
$db['production']['cache_on'] = FALSE;
$db['production']['cachedir'] = "";
$db['production']['char_set'] = "utf8";
$db['production']['dbcollat'] = "utf8_general_ci";

$db['development']['hostname']   = "localhost";
$db['development']['username'] = "";
$db['development']['password'] = "";
$db['development']['database'] = "";
$db['development']['dbdriver'] = "mysql";
$db['development']['dbprefix'] = "";
$db['development']['pconnect'] = TRUE;
$db['development']['db_debug'] = TRUE;
$db['development']['cache_on'] = FALSE;
$db['development']['cachedir'] = "";
$db['development']['char_set'] = "utf8";
$db['development']['dbcollat'] = "utf8_general_ci";

So as long as I’m not developing on the production site, I’m NOT working with production data!

By setting the MY_ENV varible there are so many other uses for detecting your enviroment.

Like for instance, only in production should emails be sent to the actual person, otherwise sent them to a defined email address. Yes I’ve seen it happen where developers accidentaly send email to users while developing. And boy do the users get confused; if not angry when this happens.

So by setting up enviroments we can ensure some safety as developers that we won’t be messing up production databases or causing existing users any distress. Plus as developers we don’t have to waste any time making config changes or worring about reverting them when we deploy the new code.