Since the webserver running redmine, or Rails to be precise – whatever it is: WEBrick, mongrel, thin, passenger… – is not designed for static file handling, you’ll most likely end up using nginx as a proxy for the upstream Rails webserver, which often listens at port 3000. Assuming you have the directory structure similar to mine, a typical nginx configuration may look like this:

server {
    listen       80;
    server_name  cool.redmine.com;

    error_log /var/www/redmine-2.0.1/log/error.log;
    access_log /var/www/redmine-2.0.1/log/access.log;

    location /(themes|javascripts|stylesheets)$ {
        root /var/www/redmine-2.0.1/public;
    }

    # proxy all other requests to thin webserver
    location / {
        proxy_pass        http://127.0.0.1:3000;
    }
}

This is kindly straightforward: nginx is configured to listen on port 80. Any public requests to the static contents (themes, javascripts, sylesheets) will be served by nginx, directly. All other requests are sent upstream to Rails webserver (thin in this case) listening locally on port 3000. We’re good to go at this point.

“How about the downloads? Shouldn’t we let nginx handle the downloads also? Nginx rocks at it!” you ask. Good question indeed, but not that simple. If we configure nginx that way, all the downloads will be open to public through nginx, which is absolutely not what we want. We want the requests to be authorized by redmine (Rails) first! So with this configuration, Rails will handle the file download requests, authorize them, and send the files on valid authorization, or an error message otherwise.

“OK so let it be. You said we’re good to go? Great, let’s just go then” you say.

Yes. But no, wait.

Indeed, with the configuration above, we’re good to go. But not *that* good. There’s a big problem lying there. And it’s about how Rails handles file downloads. To serve a file download, Rails firstly loads the whole file into memory (read: RAM) and only starts to send chunk by chunk to the client once this loading process is done. It sucks, if you ask. Even worse: the consumed memory will NOT be released, though it may be reused. Now, it sucks by a megaton! If you have a one-gigabyte file, say a Photoshop PSD, your whole server may be dead.

So now to sum up: First, we want all downloads to be authorized by Rails. Second, we want the file transfers to be done by nginx. Seems legit.

The question is, how?

As a both a nginx and Rails newbie, I dug up the whole internet for an answer. Finally, it came, in a form of – wait for it – X-Accel nginx headers. This will be the scenario:

1. Client (Chrome, Firefox, IE, you name it) sends a request to a download
2. nginx receives the request
3. It will then add some indication, literally “This guy asks for a download. Please authorize him. If OK, let me know the where the file is, so that I can serve him.”
4. It will the pass the request upstream to Rails (thin) as normal
5. Rails authorizes the request successfully
6. It will then send an internal request to nginx with the file’s real location
7. nginx happly serves the file to the lucky user

As simple as it sounds, the very few available tutorials really confused me – they’re written by advanced users, when again I’m a newbie. After hours of trying though, I finally made it. Here is the configuration which works for me:

In /var/www/redmine-2.0.1/config/environments/production.rb, before the ending end I added this line

config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect'

which instructs Rails to detect nginx’s X-Accel-Redirect header and use it instead of native Rails’ send_file. And the above nginx configuration was replaced with this:

server {
    listen       80;
    server_name  cool.redmine.com;

    # same old same old
    error_log /var/www/redmine-2.0.1/log/error.log;
    access_log /var/www/redmine-2.0.1/log/access.log;

    location /(themes|javascripts|stylesheets)$ {
        root /var/www/redmine-2.0.1/public;
    }

    # ! The following two blocks enable nginx to serve downloads instead of Rails !
    location /attachments
    {
        proxy_redirect    off;
        proxy_set_header  X-Sendfile-Type   X-Accel-Redirect;
        proxy_set_header  X-Accel-Mapping   /var/www/redmine-2.0.1/files=/files;
        proxy_pass        http://127.0.0.1:3000;
    }

    location /files {
        root /var/www/redmine-2.0.1/;
        internal;
    }

    # proxy all other requests to thin webserver
    location / {
        proxy_pass        http://127.0.0.1:3000;
    }
}

Two location directives were added: location /attachment and location /files. The first is for public requests (step 1 and 2 in the scenario). The latter is for internal requests (step 6 in the scenario). We don’t want these internal requests to be reachable by the public, hence the internal keyword. Notice these two lines:

proxy_set_header  X-Sendfile-Type   X-Accel-Redirect;
proxy_set_header  X-Accel-Mapping   /var/www/redmine-2.0.1/files=/files;

The first tells Rails that nginx will be serving the file. The second is a map, which can be literally translated into “If this file is located at /var/www/redmine-2.0.1/files, send me an internal request at /files directive.” In our case, the file is indeed at that location, so Rails will request nginx at

location /files {
    root /var/www/redmine-2.0.1/;
    internal;
}

Here, nginx serves the file, beautifully. And that’s how I did it! Let me know if this works for you as well.

But now that I have just quit my 9 to 5 life, I think I’ll dedicate some time into this blog and plugins again. So the first thing I’m doing is write a new plugin, Lazy Moderator. In short, it populates WordPress comment notification emails with true one-click-to-moderate links – you don’t have to log in and confirm. You can read more about it here or here.

The next things in plan is a complete overhaul of the old plugins. Though I have the motivation, this is not a promise, so don’t bet on it.

Wish me luck!

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:

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:

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:

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

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

<code>sudo /etc/init.d/nginx restart</code>

The result should be as followed:

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

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:

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

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:

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:

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:

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

This post is not about Stefan and his monsters however, but about some domain hack ideas that I’ve just come up with today. In case you’re not familiar with the term, Wikipedia has a clear definition for domain hack:

A domain hack (sometimes known as a domain name hack) is an unconventional domain name that combines domain levels, especially the top-level domain (TLD), to spell out the full “name” or title of the domain. Well-known examples include blo.gs, del.icio.us, and cr.yp.to.

So upon visiting The Daily Monster, I was quite surprise to see it didn’t have its own domain name. I was expecting something like thedailymoster.com or dailymonster.com or dailymonsters.com or so, but it turned out that the url was a Typepad subdomain, not a standalone. I totally believe that content is King, but a good domain name in this case would be the crown. I was telling myself “Maybe the domains had been purchased by other guys” and I was right – none of them are available.

Then, I thought based on this “one design a day” concept I’d do a similar site on my own. “Daily face”, how is that? A drawing of a face each day. I used to sketch a lot, sometimes with pencil, sometimes with the computer mouse, like this one:

The domain name I came up with was of course “dailyface.com”. Needless to say, the domain was not available. So I tried some domain hacks. The result I got in the end was dai.lyface.com. The domain name is lyface.com, and “dai” is a subdomain.

Now comes the interesting part. If you don’t notice, the domain name starts with “ly”. Which means, I can add a lot of cool subdomains. To name just a few:

• week.lyface.com
• month.lyface.com
• year.lyface.com
• ug.lyface.com
• sil.lyface.com
• friend.lyface.com
• f.lyface.com
• li.lyface.com
• on.lyface.com
• bel.lyface.com (LOL’ed at this)
• free.lyface.com
• etc. and etc.

You can see, with one domain name I can come up with many different sudomains to hold different contents. I can use “week.lyface.com” to showcase best drawing each week; same goes with monthly and yearly. You can tell similarly with ug.lyface.com, sil.lyface.com, friend.lyface.com etc. In short, any word ending with “ly” can be used to create a meaningful subdomain. Guess what, we have 8742 such words!

Image credit: ecstatistic

You get what I mean now? If you manage to get a domain starting with “ly”, the sky is your limit. The potential is huge. I don’t know if they are available or not, but here is a list of such domains I’ve just come up with: lymovies, lysports, lysports, lygames, lymusic, lysongs, lystuffs, lyeverything, lytips, lyinspirations, lythemes, lydesigns, lyhacks, lytricks, lyphotos, lypics, lystories, lyfun, lylullabies, lychance, lymeet, lynews etc.

Exactly the same concept can be applied to “ed”. Here we go: tir.edcoder.com, bor.edcoder.com, inb.edcoder.com, r.edcoder.com, hat.edcoder.com…

This is especially effective if you want to build up a network of your site, revolving a central concept.

What do you think? Am I reinventing the wheel?

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:

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:

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

Change the template name to something descriptive like “Thank You Page”, and add some logic, like this:

<?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:

<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:

<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:

<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:

<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.

A slug is a few words that describe a post or a page. Slugs are usually a URL friendly version of the post title (which has been automatically generated by WordPress), but a slug can be anything you like. Slugs are meant to be used with permalinks as they help describe what the content at the URL is.

In case you are wondering, slugs play a really, really important part in SEO. This is due to the fact that search engines like Google analyze an URL, and if it is relevant to the page’s content, the page’s rank point may be increased. Just like to us human, ?p=43 doesn’t tell anything, but how-to-create-post-slugs surely does.

So how is a slug generated? Most of the time, the post/page title is involved.

1. First, notice that all slugs are in lowercase format
2. Second, all non-alphanumeric characters – those ugly &?#$()… – are removed.
3. Third, spaces get replaced by dashes

Let’s codify them into PHP:

function create_slug($post_title)
{
    // 1. convert into lower case
    $post_title = strtolower($post_title);

    // 2. only accepts alphanumerical characters (a-z, 0-9), spaces, and dashes
    // to do that, we use some RegEx magic
    $post_title = preg_replace('/[^a-z0-9 -]/', '', $post_title); 

    // 3. replace the spaces with dashes
    $post_title = str_replace(' ', '-', $post_title);

    return $post_title;
}

Now test the function – we’ll be using some real world examples from Digg:

echo create_slug("High-Speed 'Other' Internet Goes Global ") . '';
echo create_slug('Proposed Anti-Piracy Legislation is Flawed, ISP   Says') . '';
echo create_slug('Cheetah, Gecko and Spiders Inspire Robotic Designs (PICS)') . '';
echo create_slug('In-App Sales & iTablet: The Killer Combo to Save Publishing?');

The above code produces:

<code>high-speed-other-internet-goes-global-
proposed-anti-piracy-legislation-is-flawed-isp---says
cheetah-gecko-and-spiders-inspire-robotic-designs-pics
in-app-sales--itablet-the-killer-combo-to-save-publishing</code>

Not bad huh? There are some problems however. First, if the title has continuous spaces, the slug will contains continuous dashes, which is not quite right. Second, much more important, we didn’t take into account a concept called stop words – long story short, stop words are words that don’t contain important information and are often filtered out from search queries by search engines. A list of English stop words can be found here.

With this information on hand, we improve our code a bit:

function create_slug($post_title)
{
    // 1. convert into lower case
    $post_title = strtolower($post_title);

    // 2. only accepts alphanumerical characters (a-z, 0-9), spaces, and dashes
    // to do that, we use some RegEx magic
    $post_title = preg_replace('/[^a-z0-9 -]/', '', $post_title); 

    // 3. replace the spaces with dashes
    $post_title = str_replace(' ', '-', $post_title);

    // 4. deal with stop words. I added '' (empty string) into the stop words array too.
    $stop_words = array('', 'a', 'about', 'above', 'above', 'across', 'after', 'afterwards', 'again', 'against', 'all', 'almost', 'alone', 'along', 'already', 'also','although','always','am','among', 'amongst', 'amoungst', 'amount',  'an', 'and', 'another', 'any','anyhow','anyone','anything','anyway', 'anywhere', 'are', 'around', 'as',  'at', 'back','be','became', 'because','become','becomes', 'becoming', 'been', 'before', 'beforehand', 'behind', 'being', 'below', 'beside', 'besides', 'between', 'beyond', 'bill', 'both', 'bottom','but', 'by', 'call', 'can', 'cannot', 'cant', 'co', 'con', 'could', 'couldnt', 'cry', 'de', 'describe', 'detail', 'do', 'done', 'down', 'due', 'during', 'each', 'eg', 'eight', 'either', 'eleven','else', 'elsewhere', 'empty', 'enough', 'etc', 'even', 'ever', 'every', 'everyone', 'everything', 'everywhere', 'except', 'few', 'fifteen', 'fify', 'fill', 'find', 'fire', 'first', 'five', 'for', 'former', 'formerly', 'forty', 'found', 'four', 'from', 'front', 'full', 'further', 'get', 'give', 'go', 'had', 'has', 'hasnt', 'have', 'he', 'hence', 'her', 'here', 'hereafter', 'hereby', 'herein', 'hereupon', 'hers', 'herself', 'him', 'himself', 'his', 'how', 'however', 'hundred', 'ie', 'if', 'in', 'inc', 'indeed', 'interest', 'into', 'is', 'it', 'its', 'itself', 'keep', 'last', 'latter', 'latterly', 'least', 'less', 'ltd', 'made', 'many', 'may', 'me', 'meanwhile', 'might', 'mill', 'mine', 'more', 'moreover', 'most', 'mostly', 'move', 'much', 'must', 'my', 'myself', 'name', 'namely', 'neither', 'never', 'nevertheless', 'next', 'nine', 'no', 'nobody', 'none', 'noone', 'nor', 'not', 'nothing', 'now', 'nowhere', 'of', 'off', 'often', 'on', 'once', 'one', 'only', 'onto', 'or', 'other', 'others', 'otherwise', 'our', 'ours', 'ourselves', 'out', 'over', 'own','part', 'per', 'perhaps', 'please', 'put', 'rather', 're', 'same', 'see', 'seem', 'seemed', 'seeming', 'seems', 'serious', 'several', 'she', 'should', 'show', 'side', 'since', 'sincere', 'six', 'sixty', 'so', 'some', 'somehow', 'someone', 'something', 'sometime', 'sometimes', 'somewhere', 'still', 'such', 'system', 'take', 'ten', 'than', 'that', 'the', 'their', 'them', 'themselves', 'then', 'thence', 'there', 'thereafter', 'thereby', 'therefore', 'therein', 'thereupon', 'these', 'they', 'thickv', 'thin', 'third', 'this', 'those', 'though', 'three', 'through', 'throughout', 'thru', 'thus', 'to', 'together', 'too', 'top', 'toward', 'towards', 'twelve', 'twenty', 'two', 'un', 'under', 'until', 'up', 'upon', 'us', 'very', 'via', 'was', 'we', 'well', 'were', 'what', 'whatever', 'when', 'whence', 'whenever', 'where', 'whereafter', 'whereas', 'whereby', 'wherein', 'whereupon', 'wherever', 'whether', 'which', 'while', 'whither', 'who', 'whoever', 'whole', 'whom', 'whose', 'why', 'will', 'with', 'within', 'without', 'would', 'yet', 'you', 'your', 'yours', 'yourself', 'yourselves');
    $slug = array();

    // explode() the post title into single words
    $segments = explode('-', $post_title);
    foreach ($segments as $segment)
    {
        // if the segment is not a stop words, add it into $slug array
        if (!in_array($segment, $stop_words))
        {
            $slug[] = $segment;
        }
    }

    // now convert the $slug array into a string with dashes being the connector
    $slug = implode('-', $slug);

    return $slug;
}

Run the previous example again, we have:

<code>high-speed-internet-goes-global
proposed-anti-piracy-legislation-flawed-isp-says
cheetah-gecko-spiders-inspire-robotic-designs-pics
app-sales-itablet-killer-combo-save-publishing</code>

That’s better, and this time much more usable, isn’t it? Now the next step should be the database part – create a `slug` field as a unique key, and start querying on it instead of the ID. You handle it!

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?