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.

Here is the preview of the set:

For more information and download, please head to Six Revisions’ post.

P.S. I have a plan to add some more icons into the set, so stay tuned

To a website, comments are important – this you must agree. But not all visitors leave comments – in fact, very, very few. Most of them care about the content only, and tend to leave (bounce) the site right after getting the information they need (so sad a life, huh?)

Many tips have been introduced and used to encourage visitors to contribute to your site via comments. To my knowledge, and to name a few:

• Use dofollow links in comments. By default, WordPress and other blogging systems mark links in comments with rel="nofollow" attribute. This attribute tells search engines to not follow the links, which means the commenter’s site will not be able to share any Google juice with you. While effective in fighting spammers, this technique may a bit disappoint the real visitors. Plugins like Dofollow address this problem and remove “nofollow” attribute from comment links.
• Further promote the commenter’s blog (if any). CommentLuv is a plugin that “will visit the site of the comment author while they type their comment and retrieve a selection of their last blog posts, tweets or digg submissions which they can choose one from to include at the bottom of their comment when they click submit”.
• Choose a (random) comment to give small prizes such as free ebooks, preminum themes etc.
• Explicitly ask the readers to give comments at the end of the article – “Please share your thoughts”, “What do you think?”, “What say you?” etc. etc.

Today I would like to mention another method to encourage commenting. Though this won’t likely attract more commenters, it may encourage existing ones to leave more comments and become more effective contributors.

The method is called “Thank first time commenters” and it works like this:

Normally when a visitor leaves a comment for the first time on your blog, the comment is displayed under “awaiting moderation” status and visible to him only. When there’s nothing wrong with this approach, it’s not really interesting for the commenter himself. Now how about showing him a “thank you” or “welcome” message, or better, a whole page, for the first time contributing his [great] ideas to your site? This time it’s much cooler!

Let’s turn the idea into real action for a WordPress site.

Step 1. Detect first time commenter

Original image from Chrismar

To detect whether the comment author is leaving his first comment on you site, we need to hook into one of the comment-related functions (you can read about hooks here). For this purpose I use comment_post(), but there may be some other alternatives which I don’t know about comment_post_redirect filter. This filter is applied just before WordPress redirects the commentator after him posting a comment – exactly what we need.

In the theme’s functions.php page, add these lines:

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

add_filter('comment_post_redirect', 'check_first_time_comment');
 
/*
 * This functions accepts one parameter being the location to redirect commentators to
 */
function check_first_time_comment($location)
{
    global $comment; // get the comment from global variables
 
    // if it's not "unapproved", don't modify the redirect location
    if (0 != $comment->comment_approved) return $location;
 
    // now check if it's really the first time the commenter comments
    // to do this, we check the number of comments this author have left on our site
    global $wpdb;
    $sql = "SELECT COUNT(comment_ID) from {$wpdb->prefix}comments WHERE comment_author_email='{$comment->comment_author_email}'";
 
    if ($wpdb->get_var($sql) > 1) return $location; // he's left more than 1 comment - do nothing with him
 
    //--- if we reach here, this is the first comment he leaves on our site. Do our stuffs now! ---//
 
    // first save the comment data into session. We'll use it later
    if (!session_id()) session_start();
    $_SESSION['first_time_comment'] = serialize($comment);
 
    // now modify the $location so that WordPress redirects this commentator to our special page
    return '/thank-you-for-contribution/';
}

What the code does is pretty self-descriptive. The function check_first_time_comment($location) is triggered just before WordPress redirects the commentator to a location (being the post, the page, or the error page). It takes one parameter, being the location url. Upon triggered, it checks for the status of the comment and only does its deeds if the comment is “unapproved” (status code 0). Then, it does a further check to see if this is really the first time the comment author leaves a comment on the site with the email address. If this is true, it saves the comment data into session for later retrieval, and modifies the location string to redirect the commenter to the thank you page.

Step 2. Create a “Thank you” landing page

Original image by Premshree Pillai

This is the page where our valuable commenter is redirected to. To create such a page, first copy page.php in the theme folder into thank-you-page.php. Open it and locate these lines on the top:

1
2
3
4
5

<?php
/*
Template Name: Page
*/
?>

Change the template name to something descriptive like “Thank You Page”, and add some logic, 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

<?php
/*
Template Name: Thank You Page
*/
if (!session_id()) session_start();
if (!isset($_SESSION['first_time_comment']))
{
    // the page should not be directly accessed
    header('Location: /');
    exit();
}
 
// now get the comment data from session and utilize it
$first_time_comment = unserialize($_SESSION['first_time_comment']);
// clear the session
unset(unserialize($_SESSION['first_time_comment']);
$the_post = get_post($first_time_comment->comment_post_ID); // get the post of the comment
if (empty($the_post))
{
    // for some reason, we cannot find the post.
    // The action here depends on you. For me I redirect to home.
    header('Location: /');
    exit();
}
 
// tell the browser not to cache this page in anyway
// !IMPORTANT: You may also want to exclude this page from cache plugins too!
header("Cache-Control: no-cache, must-revalidate");
 
/*
"Thank you" content goes here
With the post on hand, you can enrich this thank you page with:
- similar posts
- posts in the same categories
- random posts
- most read posts
- most commented posts etc.
*/
?>

Save the template. Now go to WordPress control panel, create a new page with “Thank You Page” as the template, and thank-you-for-contribution as the slug. You may want to disable ping and comments for the page too.

There! Your blog is now ready to welcome the first time commentators!

But wait… there’s still a catch.

Step 3. Post-production

Now, if you list down your pages somewhere on your blog, “Thank You” page will stupidly appear. The fix is easy: exclude the page ID. Also, if you have a cache plugin installed, it’s best to exclude Thank You page from caching.

Want to see it in action? Just leave a comment here as a new commentator!

If you didn’t notice, I have another site called Thica.net – Vietnam poetry network, a WordPress (what else) powered blog dedicated to poems in Vietnamese. The site is receiving about 60K of views per month, which is 12x to that of the moment when it was started back on March 2008, and I’m rather happy about it.

About one month ago, Thica.net started to become very slow and tent to produce strange problems. More than often it threw 503 Internal Server Error just when I attempt to add a new post, or 404 Page Not Found for a page that I knew it was there, such as admin panel, plugin section etc. After some deep look inside, I decided that my site was too bloated and then it was time to optimize things to start it up. To admit, the result is nowhere near perfection, but it satisfies my need. So I think I’ll share with you here.

1. Eliminate unused plugins

Original image by smackfu

Being a developer, I’m a big fan of plugins and addons. My Firefox has about 30 addons, ranging from Adblock Plus to UltraSurf (I’m living in a communist country FYI) and YSlow. Similarly, Thica.net had like 50 plugins, active and inactive alike. So you know, plugins power up WordPress in many ways, but on the downside slow it down because of all the added functions, hooks, data and so on. Some plugins are even terribly written (like one random post plugin which gets ALL posts from the database and uses PHP loop to get 5 random posts – WTH) and may cause serious problems: slowness, security holes, or even crashes your site.

So I dedicated my time filtering the plugins – which were really needed, which may be replaced by hacks and/or other inexpensive methods, which may be replaced with another plugin not as bloated, and which were totally useless. For instance, Askimet, Ozh’ Admin Drop Down Menu, Google XML Sitemaps, and Login LockDown were definitely kept. I’m now using my own functions to get the random and most read posts, searching for a SEO plugin in place of All In One SEO Pack as for some reasons Platinum SEO Pack didn’t fit my needs, and have trashed away tens of unused plugins. By “trashing away”, I mean deleting from the hard drive, as inactive plugins still waste WP resource – it still has to look them up and check for their status anyway.

2. Use a total cache solution

Original image by adesigna

To a busy application – web or non-web alike, caching is vital. For as far as I know WordPress is not as bloated as other CMS (Joomla, Drupal, Magento to name a few), but its performance has rooms to be improved. I had been using WP SuperCache for quite a while and the performance was good enough, until the problems occurred and I realized that it had some extra features that I didn’t need at all. Then I sought out for some alternatives, like W3 Total Cache, Crazy Cache etc. HyperCache is where I stopped at – just a matter of personal opinion, and I’m happy with it so far.

But HyperCache alone was not enough in my case. Don’t you know that for a complete page to be served, WordPress has to make like a bunch of continuous calls to the database? My Thica.net for instance, makes an average of 50 MySQL queries for the home page and 80 to 90 queries for each single page. That’s rather expensive isn’t it?

Lucky me, there’s another kind of caching solution called database caching. As most of the query results don’t change from time to time – the post content, the categories, the tags… often remain the same – they can be cached for later use. For this purpose I installed DB Cache Reloaded and – just like magic – almost all of the queries (85 over 90 for example) are now served from the cache. You must admit, that’s a huge improvement. My host should thank me for not bombing their server!

3. Staticalize WordPress variables

WordPress is so flexible – almost anything can be customized. That’s definitely great. But sometimes the greatness comes a bit too far from necessity. If you open a normal header.php file from a normal theme, 99% chance is you’ll see these lines:

1
2
3
4
5

<html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>>
<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />
<title><?php wp_title('&laquo;', true, 'right'); ?> <?php bloginfo('name'); ?></title>
<?php bloginfo('stylesheet_url'); ?>
<link rel="pingback" href="<?php bloginfo('pingback_url'); ?>" />

You guessed it, these scripts get the settings from the database. Now let’s face it: how often would you change your blog name, or the language, or the style sheet URL, or the HTML charset? For me, it’s once and for all. vi-VN is my site lang, charset is of course UTF-8, and I don’t have any intention to change them ever. That’s why in the theme, I replaced the dynamic scripts with static content whenever applicable:

1
2
3
4
5

<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="vi-VN">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" href="http://static.thica.net/css/notepad-chaos.css?ver=1.2.21" type="text/css" media="screen" />
<link rel="pingback" href="http://www.thica.net/xmlrpc.php" />
<!-- and so forth -->

This way I saved quite a few of unnecessary queries and made my site run a bit faster.

4. Follow Yahoo’s optimization tips

Have you taken a look at Yahoo!’s Best Practices for Speeding Up Your Web Site? It is an awesome resource for those who want to optimize their blogs for performance. Among the rules, these are particularly useful for my case and have been implemented:

4.1. Add an Expires or a Cache-Control Header

Original image by laffy4k

An Expires header lets the browser have an idea of when the requested content is expired and needs to be re-downloaded. By setting a content’s expires header to a far future, you can tell the browser to use the local cached copy instead of retrieving a fresh version from the server, thus save both bandwidth and loading time. Perfect candidates for this are the images, css, javascript etc.

In the .htaccess file of Thica.net’s root directory, I added these lines:

1
2
3
4
5
6
7
8

<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 10 years"
ExpiresByType image/png "access plus 10 years"
ExpiresByType image/jpg "access plus 10 years"
ExpiresByType application/x-javascript "access plus 10 years"
ExpiresByType text/css "access plus 10 years"
</IfModule>

These lines mean “These images, javascript, and css includes will not be changed for 10 years more, so dear Firefox/Chrome/Opera/Safari/IE, please use their copies from your cache whenever applicable and don’t put the heavy load on me, thanks”. The so understanding browser will be ok with such a polite request, and tada, all the specified contents are loaded from the cache in a blink of an eye.

4.2 Gzip Components

Original image by Isobel T

Now-a-days, all modern browsers support gzipped components. Imagine it like this: first the browser requests for a page. Instead of returning the page as is, the server compresses it and sends the archive back. The browser receives the archive, decompresses it into normal state, and renders the decompressed content normally. Like WinZIP or WinRAR does, but in a web context. Simple?

To take advantage of this technique, once again I opened the .htaccess file and added these lines:

1
2
3

<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript
</ifmodule>

This configuration forces the server to gzip those MIME contents before returning them to the browser. Made a quick test at the GIDZipTest fot the homepage and I received this result:

So, 3 lines added into the .htaccess file and I reduced 76% of bandwidth (means loading time cut down to 24%). Marvelous.

4.3 Split Components Across Domains

Original image by Jamison_Judd

Browsers have a limit on how many parallel requests can be sent – it’s 2 for Internet Explorer and 4 for Firefox (configurable, but can’t exceed 8 if I’m not wrong). This is a per domain value. It is advised that a site’s components should be distributed on more than one domain to maximize the parallel downloads. So if your HTML is served from site.com, your images are located on img.site.com, and your css files are put on static.site.com, the number of maximum parallel downloads a browser can perform on your site are tripled, and the loading time may be cut by two third or so.

That’s why I created two subdomains: img.thica.net for the theme images, and static.thica.net for other static contents like style sheets and javascripts. The performance is significantly improved – my site often finishes loading before I knew it, period.

The result so far

Well, my site ran much faster. Unfortunately, the errors kept occurring from time to time still. From the error logs, it showed that somehow my php5 CGI processes were terminated now and then, hence the 503 and 404 errors.

I contacted my host. They said my site was using too much of resource. I told them that a WP-powered site with 2K to 3K of views per day and 2GB of bandwidth a month could hardly use too much resource. So they were like: bandwidth and resource are not the same. Then they blamed my PHP scripts, saying that All in One SEO Pack sucked. “Then how come it’s so widely used around this earth?” I asked. They kept silence, the errors kept happening.

I was forced to use my final weapon.

5. Switch to another host

Yes, the final step I took was switching to another host. I asked for reference from many people, and later got convinced by Jean Baptiste Jung, the famous guy behind WPRecipes, CatsWhoCode, and most recently CatsWhoBlog, to go with WPWebHost (many thanks, Jean!). It was not a smooth migration to be honest, as I had 4 or 5 sites to be relocated, when my old host doesn’t use cPanel for site controlling. But what I do really, really appreciate is, no matter what the problem was, no matter small or big, they were always there, supportive and helpful.

Well I don’t want to sound like a salesman, but WPWebHost really rocks. So if you are planning for a move, I highly recommend them. The banner above is in fact an affiliate link, so I would appreciate a lot if you purchase their hosting package via clicking on it

The final result

That’s it – my journey to optimize my Thica.net to make it speedy, and I’m really pleased with the result: faster load, light footprints, no stupid errors, minimum bandwidth. You may want to check the result yourself at the site itself. What do you think about it / this article / my pidgin English / my bad writing? I’m happy to see your comments.

So, instead of developing the enhancement as a new feature for Free CDN, I decided to create a new plugin called CDN Rewrites. The implementation was not really a breeze, but in the end it worked rather smoothly.

I would like to thank Mike Colburn for the idea and being so kind enough to help me with all the documents and testing. Without him this plugin would never see the light.

Head here for the plugin’s official page.

I’m rather lucky to be working as an R&D guy in my current company, thus got a (legal) chance to (legally) spare a lot of time for (sometimes illegal) new and cool stuffs. Among them is CDN, a solution to distribute (mostly static) contents across a network and let end-user access their copies from the cloud instead of the central server itself, thus reduces bottle neck problems during peak hours. To enterprise websites like those of Microsoft, Yahoo, Amazon, eBay etc., this is vital, as the number of concurrent visitors and downloads very frequently exceeds millions. Some of them build their own CDN, when the others rather hire third party services to handle the load to save time and money. Most well known among these 3rd services are properly Akamai and Limelight, though there is a vast of them, naturally. For instance, Windows 7 downloads (~2GB each!) were served through Akamai network, when the live internet broadcast of Barrack Obama’s inaugural speech was done with help from Limelight.

CDN’s are great as they save websites from heavy loads thus reduces bandwidth and shorten that number on the webmasters’ monthly bills. So why aren’t they used so popularly? Well, because in general they are expensive, as you can tell. Depending on each CDN’s price table and the data size, the cost of using a CDN may range from thousands a month, which is unaffordable for like 98% of our blog owners despite of being just a peanut to Yahoo and Microsoft. So unless he is earning millions from selling Photoshop brushes or Google ads on his personal blog, a blog owner would close his eyes and wait for that Digg wave to calm down instead of (dare) using a CDN and survive the typhoon. So the rich keep getting richer and the poor keep remaining poor, life is bitter huh?

Not really (whoo hoo!). Akamai and Limelight are big, but they are not the only. Aside of those commerical CDN’s, there are some free ones, like Coral, which provide us with free CDN – means free bandwidth. Coral CDN uses peer-to-peer technology in its CDN architecture, thus eliminates the need of maintaining a system of expensive server clusters while still offering an CDN solution with acceptable speed and stability. Long story shot, we small blog owners can also have CDN (on pair with Microsoft, yay!).

It’s dead simple to get a content (being any of types, but most commonly static contents like images, video clips, music tracks, css, java scripts) served thought Coral. All you have to do is appending .nyud.net to the host name of that content’s URL and call it done. Try it here, here, and here to see it yourself. The first time requested, the content is retrieved from the original server and cached on Coral’s distributed servers. From the second request on, visitors will get a copy of that content from Coral. If the content weights 100KB in size, you’ve just saved 100KB bandwidth. If you have 1000 requests, it’s 100MB of bandwidth saved. Piece of cake.

So I was very excited getting to know about Coral and free P2P CDN’s. Then I told myself: ok, it’s time for another WordPress plugin – a “Free CDN” one which will rewrite all static URLs (being images, css, js etc.) to take advantage of Coral. Easier said than done, but nonetheless, I managed to get it done (thank you very much Thaya, for the great help on how to capture the whole WordPress HTML stream). Today is the day Free CDN WordPress plugin is born, cheers! The concept behind this plugin is simple: it looks for static contents inside a WordPress page and rewrites them into Coral-ready format. For example, http://www.yourblog.com/wp-contents/themes/one-room/images/sprites.png will be rewritten into http://www.yourblog.com.nyud.net/wp-contents/themes/one-room/images/sprites.png and gets handled by Coral network.

If your blog is rather small and you don’t have to worry about bandwidth fee / peak times, then it may be not worth your time to lay an eye on this plugin. But if you have a big enough blog with tens of thousands of views a day, and the bandwidth fee is giving you some good nightmare, and the bottle necks are causing you some headaches, then why not give Free CDN a try?

I curiously did some “research”es (well, another buzzword), and it seems in order to create the shorten URLs they are following the same steps:

1. Insert the original (long) URL into the database
2. Get the insert ID. If the URL already exists, take its row ID. Let’s say we got 123456.
3. Convert the ID 123456 into something even shorter, let’s say “am4k”
4. Make use of Apache’s mod_rewrite so that any request to http://host.com/am4k will reach http://host.com/redir_script.php?code=am4k instead.
5. In redir_script.php the value “am4k” is converted back into base10′s 123456 and the corresponding URL is queried back from database
6. If a URL is found, redirect the request to it.

It is simple enough… except for step 3 and 4. Which conversion is there, and how is the .htaccess written?

So I did some other buzzword-here, and it turned out base36 encoding is taking place. According to Wikipedia, “the choice of 36 is convenient in that the digits can be represented using the Arabic numerals 0-9 and the Latin letters A-Z”. There is a handy conversion table too:

Even better, PHP takes only one line of code to convert between decimal and base36, as shown on the same Wiki page:

1
2
3
4

$base_36 = "ZAQFG"; //Sample Base 36 Number
$decimal = "7654321"; //Sample Decimal Number
echo base_convert($base_36,36,10); //Outputs $base_36 converted to decimal
echo base_convert($decimal,10,36); //Outputs $decimal converted to base 36

In our example, 123456 will be converted into its tidy equivalent base36 2n9c (not am4k, my very bad).

As for the mod_rewrite thing, as I am not a .htaccess master, I copied this thing that has been working perfectly so far from CodeIgniter forum:

1
2
3
4
5
6
7
8
9
10

RewriteEngine On
RewriteBase /
 
#Checks to see if the user is attempting to access a valid file,
#such as an image or css document, if this isn't true it sends the
#request to redir.php.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ redir.php?code=$1 [L]
 

With this, all of the hardest parts are done, leave the remains being simple MySQL database, queries and HTML form handling. To save you from getting boring, I’ll omit it.

Instead, let’s see a demo hereThe source code of the demo are can be downloaded from the same server

1. The code has been COMPLETELY re-written from scratch. As of the previous versions, it was one big file that handled everything from admin to front-end control. Needless to say how inconvenient this approach had become when bug fixes and new features were added… too bad that I have decided to throw all away and build a brand new OOP Referrer Detector. Well, it was a looong and tough way, but I’ve never looked back!
2. The data are now in (ahem) database. I was thinking (and convincing myself) that a JavaScript file is faster, as it reduces the number of database requests. But with time, it becomes too bloat and too hard for me to track bugs as well as to add improvements. So I told myself: hell with this sacrifice, I better obey the power of MySQL.
3. The biggest new feature that I’m really excited of is the ability to add localized messages. In the past, your users were welcomed the the same (English) greetings regardless of which country they were from. Now you can specify a localized message for those from Vietnam, another for Brazilians, Portuguese, and so on. The plugin will try to detect users’ country and decide which message to show. Isn’t it cool?
4. The second new feature is the ability to backup and restore stuffs, including entries, excluded URLs, and options. For restoring, in order to keep the administration panel AJAX’ed, I go with Uploadify, a wonderful jQuery file upload plugin. This plugin uses a bit of Flash, but no worries, it will still works if your browser has no Flash player installed.
5. For the Stats panel, there were two problems that caused me much of headache. One is Google TLDs which are hundreds in number thus totally ruined the chart. The other is the chart itself: PHP/SWF Charts library is too darn heavy and often broke my SVN commits. So I wrote some code to group those annoying TLDs into one group, and use Google Chart instead.
6. In the admin panel, I added a “Support this plugin!” tab. Just a bit about myself, like “Follow me on Twitter”. Hope you aren’t pissed of with this change.

As usual, the plugin is downloadable at WordPress Codex. Your comments are always welcome here and in the plugin page. Let me know if you’re happy with the new version, or about the bugs you encounter!

Code snippet #2 – Shorten Links Using Bit.ly

Purpose

Create a shortened URL using Bit.ly. This is extremely useful for your visitors, as they don’t have to look any further – just grab it to use right away.

Requirements

• A Bit.ly account (and API key). You can create one for free at their site in seconds. Once logged in, head to Account section and look for a long ugly string starting with “R_”.
• PHP 5 >= 5.2.0. Your host doesn’t support PHP 5? Claim your money back and find another host.

The Code

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

function get_shortened_url($url)
{
    $bitly_api_key = 'YOUR KEY HERE';
    $bitly_username = 'YOUR BIT.LY USERNAME HERE';
    $data = file_get_contents("http://api.bit.ly/shorten?version=2.0.1&longUrl=$url&login=$bitly_username&apiKey=$bitly_api_key");
 
    $data = json_decode(utf8_encode($data));
 
    if ($data->errorCode)
    {
        return false;
    } 
 
    return $data->results->$url->shortUrl;
}
 
// now use it
echo get_shortened_url('http://www.example.com/this-is-a-stupid-long-long-long-url.html');
 
// how about WordPress?
// Just place the function above somewhere in your functions.php theme page and then
 
// 1. inside The Loop
echo get_shortened_url(get_permalink());
 
// 2. outside The Loop
echo get_shortened_url(get_permalink($post->ID));