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?

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!

6. Though my knowledge is very very very humble, I sometimes do tutorials (don’t laugh, what a shame :”>), for example, this and this which have been receiving a few of visitors from Google. In these tutorials, I posted some source code – HTML, XML, PHP, Javascript, CSS etc. In order for them to be clearer to read, I highlighted them. How? Did I have to color each and every span? Nope. WP-Syntax is the key. This Geshi supported plugin did everything for me. Install and activate it, then wrap the code block into a <pre></pre> pair with a specified lang attribute, there, it’s done.

7. Do you notice that out of the box, the comment boxes provided by WordPress look very simple (read: ugly)? I do. And I hate it, especially comparing with the much more functional reply boxes in those forums out there. So I looked for a way to add my comment boxes some extra power, and finally stopped at MCEComments, a plugin that integrates TinyMCE into a WordPress comment box, giving it a lot more features. I’m pretty sure there are some other plugins that share the same purpose, but I’m not that picky – since MCEComments perfectly worked for me from the beginning, I’ll stick with it.

8. Just like all other plugin developers, I have a development version of this blog, as described in one of my previous posts. That post mentioned that I used WP-DBManager to create a backup of my live database. Though in another post, I talked about the possible vulnerability this plugin’s users may encounter if by any chance don’t strictly follow the instructions, this plugin is still a must-have. Almost every database-related actions can be performed through it: you can optimize, repair, empty/drop tables, run specific SQL queries, and most important, set up an automatic schedule to back up your database. No matter how big your blog scale is, keeping backup(s) of your database is a must. For this reason, having WP-DBManager healthily activated is vital.

9. For user experiences and interactions, I use 3 plugins in a row: ShareThis, Digg This O’ Mine, and Referrer Detector. The first is so famous that I see it on almost every blog – it allows blog owners and visitors to submit a post which they feel interesting to plenty of social services: Digg, Reddit, StumbleUpon, Delicious etc.

The others are my own plugins, very simple, but fits my needs .

11. It is also a good idea (that I borrow from others) to have an “Other Posts” section on a post page – this reminds visitors to explore other (interesting) contents. I used to use Random Posts plugin to randomly display other posts, until I one day realized that it doesn’t work so well with WP-Super Cache. So I decided to write and use my own AJAX Random Posts. It’s a humble plugin (just like all other ones from mine), but again, it fits my needs, so still I’m using it.

12. Finally, for all these plugins, believe it or not, I didn’t have to download any them from WordPress codex repository, ever. Everything was automatically done by an extremely useful plugin called WP Easy Uploader. I downloaded, uploaded, activated (and configured) this one the very first. From then on, every time I need to upload a plugin, I just need to head to Tools:Upload Files, paste the download link into the URL text field, specify that it’s a plugin, and click the cute “Upload” button at the bottom. The plugin archive file will be grabbed from WordPress codex server and extracted just in place.

Yes, I know that with the 2.7 version of WordPress coming out, we have a neaty plugin installer built-in. But WP Easy Uploader still remains one of my most favorite plugin. The first reason is that it works for almost everything, not just plugins alone. With it, I rarely have to fire up FileZilla anymore. And you can tell, this seriously satisfies my laziness. Hehe. Hehe. Hehe.

So how about you? Do you have any recommendations or cool stuffs to share? How about trying my MCEComments-powered comment box right now?

Well, enough of babbling. What I wanted to say is, today I’m going to write down here list of plugins I’m currently using on this site. For what, you ask? To show off, of course. Or – I prefer this – to share something that may be useful sometimes.

So in no particular order, here they come.

1. I use WordPress.com Stats to have a in-details view on my blog. Five or ten times a day, I click “Blog Stats” link in the admin panel to get an idea on the traffic, incoming/ongoing links, search terms etc. All these data are essential if I want to build up a high quality site.

2. To save a lot of clicks and keep the admin menu bar tidy, Ozh’ Admin Drop Down Menu is my plugin of choice. Agree, the new menu system in WordPress 2.7 is a good improvement, but it’s still nowhere near Ozh’s version. Write a new post, customize the theme, add a new plugin, change some settings… almost all the commands are now just one-click away from me. Huge productivity, I’d say.

3. When it comes to SEO, All in One SEO Pack definitely suits my needs. I didn’t need to do anything, just installed it and all the keywords, titles, descriptions were there beautifully. Sure, there are plenty more than just than for SEO (like the incoming links) but that should be basically enough for a good start. So if you’re coming from Google, this plugin deserves some credits.

4. And some other credits should go to Google XML Sitemaps. This plugin automatically generates a XML-Sitemap compliant site map for me every time I add/edit/remove my posts and pages, so that MSN, Yahoo, Ask, and Google bots can easily browse (and index) my site. I don’t even want to imagine just how long and boring it would be if I had to manually modify my site map after there was a change in the architecture, so this plugin is a must-have.

5. I’m not a good writer. Especially when English is not my mother language. And my articles are boring. So I guess that’s why I’m not receiving many comments from my readers. From those darn spammers however, well, there’s a bunch of spams almost every day. But you don’t see any of them, right? It’s totally thanks to the Askimet spam fighter. I installed it from the beginning of this blog, and since then there is 0 missed, around ten false positives on over 500 spamming comments got caught. Impressive, huh?

(to be continued)

But today I noticed this DANGEROUS thing, and I want to announce it so that everybody can fix. By default, sql dumb data are saved into files under a directory named backup-db inside wp-content. And this directory has absolutely no protection. That means you can freely browse anyone’s wp-content/backup-db/ content and download the data file.

Now, I did a search of “index of /wp-content/backup-db” on Google. From the popularity of WordPress and this plugin, you can tell how many results I got. Yes, thousands of results were returned, each was a browsable and downloadable backup directory among thousands of different WordPress-powered websites.

Need I stress on how serious this problem is? It’s about passwords (encrypted or not), email addresses, other private data, even credit card numbers for business blogs. This is serious.

The fixes

There are many fixes for this problem. You can

• Change the backup directory, or
• Upload a index.html file into backup-db directory to prevent directory browsing, or
• Use .htaccess to prohibit downloading contents from the directory etc.

For the sake of WordPress users, please spread this. I’ve also contacted Lester Chan, the author of the plugin, so that he can release a fix.

Updates

It seems I missed the instruction from the author before installing the plugin
But anyway, I believe most of WP users just install the plugins without reading, especially when they just work out of the box. And as the downloadable sql dumps are still out there, I’m waiting for a more strict fix instead of readme file’s instruction.

UPDATE: Starting from version 2.50, the plugin author added a check for a proper .htaccess file in the backup folder for security purpose. Way to go!

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

Nevertheless, I’ve just taken part in this community for 2 months, so I would consider this a small success.

And this is a win-win.