It’s fairly simple to set up and get nginx running with FastCGI and MySQL on Ubuntu – a very well-written tutorial can be read on HowtoForge, which should take you less than 15 minutes for everything. In this article therefore I will only write about how to configure nginx to actually run a Kohana-powered site, with virtual host and rewriting and such. If you’re not familiar with Kohana, take a look at my article here.

The prerequisites

• I have my Kohana-power site located under /home/phoenixheart/www/my-kohana/ directory with proper permission set (owner being www-data, that is).
• nginx has been set up properly and listening on port 80, with the configuration directory being /etc/nginx/
• I want my site to be locally accessible via my-kohana.dev. Any requests to www.my-kohana.dev should be permanently redirected to my-kohana.dev – which is also called “force non-www”.
• I want to have neat URL rewriting without “index.php”, for example index.php?controller=product&function=get&id=1 should be rewritten into /product/get/1
• I also want that all existing files and directories under the root directory are accessible, except Kohana’s system directories system, application, and modules. Any attempt to access system files and directories(beginning with dots, like .htaccess or .settings) should be disallowed also.

All clear. So let’s do it!

Set up the virtual host

The way nginx handles virtual hosts is totally different from Apache, as we can expect. Instead of using .conf files to declare and configure the hosts, nginx, when started, additionally scans through the configuration folder (/etc/nginx in our case) to find (if any) configuration files under 2 directories: sites-available and sites-enabled. So under /etc/nginx/sites-available, create a file called my-kohana.dev with the following content:

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

server {
    listen   80;
    server_name my-kohana.dev;
 
    access_log /home/phoenixheart/www/log/my-kohana/access.log; # remember to create this file
    error_log /home/phoenixheart/www/log/my-kohana/error.log; # and this file

    location / {
	root   /home/phoenixheart/www/my-kohana;
	index  index.php;
    }
 
    location ~ \.php$ {
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME  /home/phoenixheart/www/my-kohana$fastcgi_script_name;
	include        fastcgi_params;
    }
}

Of course, this is just the basis configuration for the site to get up and running. To continue, we must create a host entry. Open /etc/hosts and add this line:

1

127.0.0.1	my-kohana.dev www.my-kohana.dev

If this was Apache, we would be good enough to restart the webserver to see the result. But like I said, nginx is different. For nginx to properly recognize and serve our site, we must enable the site by creating a symlink of the configuration file under sites-enabled. We do that as follow:

ln -s /etc/nginx/sites-available/my-kohana.dev /etc/nginx/sites-enabled/my-kohana.dev

Now, let’s restart nginx. Open Terminal and type:

sudo /etc/init.d/nginx restart

The result should be as followed:

Restarting nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
configuration file /etc/nginx/nginx.conf test is successful
nginx.

If you receive any “failure” response, chance is some typos in the configuration.

Now, http://my-kohana.dev should be accessible via the browser (Note that, if Kohana complains about the logs folder inaccessible, try properly setting its owner to www-data). Next step is tweaking the configuration a bit to serve our needs.

Tweak it up

Force non-www

To force non-www, open sites-available/my-kohana.dev and add these lines at the top:

1
2
3
4
5

server {
    listen 80;
    server_name www.my-kohana.dev;
    rewrite  ^/(.*)$  http://my-kohana.dev/$1  permanent;
}

This kind of configuration is very similar to that of Apache, so I would assume there’s no need to explain. After a nginx restart, all request to http://www.my-kohana.dev should be silently redirected to http://my-kohana.dev.

Neat URL rewriting

Again, in sites-available/my-kohana.dev, modify the first location block to the following

1
2
3
4
5
6
7
8

location / {
    root   /home/phoenixheart/www/my-kohana;
    index  index.php;
 
    # this is where the rewriting gets done.
    # refer to http://forum.kohanaphp.com/comments.php?DiscussionID=1505 for more info
    rewrite ^(.+)$ /index.php?kohana_uri=$1 last;
}

But wait! We don’t want EVERY requests to be re-written. For example, a request to my-kohana.dev/css/style.css should be kept as-is. Same goes with javascripts and images. In short, if the request is for an existing file or folder, we keep it as-is; else, we route it to index.php using rewriting. To achieve that, modify the configuration above to this:

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

location / {
    root   /home/phoenixheart/www/my-kohana;
    index  index.php;
 
    if (-f $request_filename) {
        # translated into "if the request is an existing file, break (do nothing)"
        break;
    }
    if (-d $request_filename) {
        # translated into "if the request is an existing directory, break (do nothing)"
        break;
    }
 
    # the request is not an existing file or directory
    # this is where the rewriting gets done.
    # refer to http://forum.kohanaphp.com/comments.php?DiscussionID=1505 for more info
    rewrite ^(.+)$ /index.php?kohana_uri=$1 last;
}

Set files and folder accessibilities

Now, we prohibit access to the sensitive stuffs, including kohana system folders, dot files and directories etc. It’s fairly simple with nginx. All we need to do is adding two more location blocks, specific for this purpose:

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

location ~ /\. {
    return 404;
    # or, if you prefer
    #return 403;
    # or even
    #deny all;
}
location ~* ^/(modules|application|system) {
    return 404;
    # or, if you prefer
    #return 403;
    # or even
    #deny all;
}

The final configuration file should look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

server {
    listen 80;
    server_name www.my-kohana.dev;
    rewrite  ^/(.*)$  http://my-kohana.dev/$1  permanent;
}
 
server {
    listen   80;
    server_name my-kohana.dev;
 
    access_log /home/phoenixheart/www/log/my-kohana.dev.access.log;
    error_log /home/phoenixheart/www/log/my-kohana.dev.error.log;
 
    location ~ /\. {
        return 404;
    }
 
    location / {
        root   /home/phoenixheart/www/my-kohana;
        index  index.php;
 
        if (-f $request_filename) {
            # translated into "if the request is an existing file, break (do nothing)"
            break;
        }
        if (-d $request_filename) {
            # translated into "if the request is an existing directory, break (do nothing)"
            break;
        }
 
        # the request is not an existing file or directory
        # this is where the rewriting gets done.
        # refer to http://forum.kohanaphp.com/comments.php?DiscussionID=1505 for more info
        rewrite ^(.+)$ /index.php?kohana_uri=$1 last;
    }
 
    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /home/phoenixheart/www/my-kohana$fastcgi_script_name;
        include        fastcgi_params;
    }
 
    location ~* ^/(modules|application|system) {
        return 403;
    }
}

After another nginx restart, our Kohana instance should run without any hassles.

Typos? Mistakes? Errors? Let’s hear it in your comment.

So after that stupid “accident”, I decided to keep myself out of those risks. I installed a local development version of Thica.net on my own PC. It was a true breeze – very easy and fast. If you’re like me – always living on the news trying new cool stuffs – then here is a step-by-step guide, with no or very little coding involved. Even better, all software to be used are free/open source.

Step 1: Downloading XAMPP

I always prefer quick and easy ways. So to setup a server that hosts my development copy, instead of seperatedly download and install and configure those complex Apache, MySQL, PHP, I obtained a copy of XAMPP which is a package with all Apache, MySQL, and PHP bundled (in case you’re wondering, X stands for “all major operating systems”, A for Apache, M for MySQL, 1st P for PHP, 2nd one for Perl).

Step 2: Installing XAMPP

The installation was dead simple. Just run the downloaded executable file, click Next, Next, Next, then done. By default, the XAMPP files are saved at C:\xampp, but I chose to place them under E:\xampp\xampp, just by habit.

Just before the installation is finished, XAMPP will start Apache, PHP, and MySQL as services. If for any reason it doesn’t, you will head to its installation folder, start XAMPP control panel by double clicking xampp-control.exe, and manually manage those services there.

Now the server is basically ready to rock. Piece of cake, isn’t it? Now on to the next steps.

Step 3: Copying the files

Now, for the content, first I created a directory called “thica.net” in my XAMPP’s htdocs folder. To fill it up, I fired up my all-time favorite FTP client FileZilla and started downloading everything from my server.

Of course you may use some plugins out there or the useful backup feature of cPanel to get the server content into one archive and extract it on local. Whatever it is, just make sure the contents of you remote site and local folder are identical.

Step 4: Creating the local database

Now we’ll have to run the SQL dump file just downloaded toward the local MySQL to create the local database. Any MySQL front end utility can do this, but I used the most popular phpMyAdmin which should be built-in already at http://localhost/phpmyadmin/ right after XAMPP was installed (remember it?). Well, just click “Databases” and locate “Create databases” section.

Note that I set the database collation as “utf8_unicode_ci” which is the best in most cases.

Step 5: Backing up the remote database

I used a extremely useful plugin called WP-DBManager to backup the whole server WordPress database into one SQL dump. After installing and activate the plugin, just head to Database -> Backup DB and you’ll be served with something similar to this screenshot:

One the database was backup, I downloaded the dump file to my local machine and process to the next step.

Step 6: Populating the local data

Now, with the SQL dump in my hand, we’d need to populate it so that the data is the same as that of the remote server. For this, I accessed http://localhost/phpmyadmin/ again, selected the database “thica” created in step 4 and clicked “Import”. In the new screen, I browsed to the SQL dump file (of course you will need to extract it if it’s gzipped), and clicked “Go” button. In a matter of seconds (actually it depends on your database size) phpMyAdmin will transfer the data and I’ll have an exact copy on my local machine.

Step 7: Some configurations

Now for the development version to be able to connect to and query the local MySQL database, we’ll have to configurate a bit. Open the file wp-config.php in your local wordpress folder (we’re talking about my site, then it’s E:\xampp\xampp\htdocs\thica.net) with any plain text editor and locate some lines similar to these:

1
2
3

define('DB_USER', 'remote-mysql-username');     // Your MySQL username
define('DB_PASSWORD', 'remote-mysql-password'); // ...and password
define('DB_HOST', 'localhost');     // ...and the server MySQL is running on

Change these variables into the local values which can be set in http://localhost/security/xamppsecurity.php. In my case, it is:

1
2
3

define('DB_USER', 'root');     // Your MySQL username
define('DB_PASSWORD', ''); // ...and password
define('DB_HOST', 'localhost');     // ...and the server MySQL is running on

Then I saved the file.

Step 8: Creating a virtual host

Next I decided to create a virtual host instead of using the dumb and inconvenient http://localhost/thica.net url. It’s never been that easy with XAMPP

First I opened the file httpd-vhosts.conf in E:\xampp\xampp\apache\conf\extra folder with Notepad++ and added these lines at the very bottom:

1
2
3
4
5
6

NameVirtualHost thica.dev:80
<VirtualHost thica.dev:80>
ServerName www.thica.dev
ServerAlias thica.dev
DocumentRoot "E:\xampp\xampp\htdocs\thica.net"
</VirtualHost>

This will instruct Apache to create a virtual host that we can access at the url www.thica.dev, with the content served from E:\xampp\xampp\htdocs\thica.net folder.

Next I opened the “host” file (no extension!) in C:\WINDOWS\system32\drivers\etc and added this line:

1

127.0.0.1	thica.dev www.thica.dev

Then at the XAMPP Control Panel, I restarted Apache by stopping and starting it. The virtual host is ready

Step 9: Final touches

With the files already in place and the database ready to server, I accessed www.thica.dev in my browser. But how strange… instead of the local development site, I was redirected to http://www.thica.net. It turned out that WordPress had some settings that takes effect in this here:

and here

So, using phpMyAdmin, I changed both values into http://www.thica.dev. Now pointing my browser to www.thica.dev works!

But wait… I’m a perfectionist, and I want more. There is a FireFox addon called Server Switcher which helps us switch between the Live and Development versions with just one click. Yes, it may sound small, but it certainly comes in handy. So if you want it perfect, install this little plugin.

Step 10: Enjoy

Now everything should be in working order. Is there anything else, or am I missing anything here? Please leave your comment