On the magical date 8-8-2008 PHP 4.4.9 was released, the absolutely last release in the PHP4 branche. PHP 4.4.9 has some important security fixes:

• Updated PCRE to version 7.7.
• Fixed overflow in memnstr().
• Fixed crash in imageloadfont when an invalid font is given.
• Fixed open_basedir handling issue in the curl extension.
• Fixed mbstring.func_overload set in .htaccess becomes global.

Support for PHP4 has now officially ended.

Tonight I had trouble with parsing url’s.

I wanted  to create some SEO-friendly url’s for a new site and the PATH_INFO server variable is a good base for it.

My url:

site/productname/camera

It’s easy to parse the url to segments with an explode on “/”

But I had a specific url that caused me troubles:

site/productname/cameraz.

Strangely  the  trailing dot disappeared:

echo $_SERVER['PATH_INFO']
site/productname/cameraz

while

echo $_SERVER['REQUEST_URL']
site/productname/cameraz.

That’s weird. I never saw those differences before.

I tried it on an old server with php 5.1.2. And NO difference there.

Somehow a bug entered in php 5.2.5 that deletes a trailing dot in $_SERVER[‘PATH_INFO’].

Be aware!

Of course it can also be caused in interaction with the apache-server.

Consider an RSS feed read in as an SimpleXMLobject $rss.

What’s the difference between:

foreach ($rss->channel as $channel) {
...
}

and
$foo = $rss->channel;
foreach ($foo as $channel) {
...
}

Not much you would say, the first code example is shorter and more to the point. However when putting the scripts to work, (with a big rss file) we’ll soon see the difference.

Memory problem and a growing swap file

After a while the former example is causing a lot of disk activity and you will see your swap file grow and grow, at my computer it reached the maximum of 4 GB and off course it took ages for the script to finish.

And all that while the maximum memory usage for a script is set to 24MB in php.ini. Should run in a 1G computer you would say.
Well example 2 does but example 1 does not!

Is seems that iterating over an object-property in a foreach loop is troubled by a memory leak.

Solution

Example 2 is the workaround!

Conclusion

PHP 5.1 until 5.2 seem to suffer from this memory leak.

One day I noted that my blog was showing an SQL-error in the LINKS section. What a surprise? How come?

I had no idea what action caused this fault, was it a stupid edit somewhere, a bad internet connection while updating my blog or a half succeeded hacking attempt?

SQL-syntax errror

The error was this:

WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1]
SELECT cat_id, cat_name FROM

And it appeared under the Link/Blogroll section.

What could have caused the problem?

Well, what I knew was that I had updated MyBelovedPHP to the newest version of WordPress 2.2 a few weeks ago. The update seemed to work without problems, but probably I hadn’t scrutinized my blog for a 100%.

I could remember that 2.2 was only suited for PHP 5 version, PHP 4 was no longer supported. OK, but I had PHP 5 on my server. What then?

SQL is database related, what were the changes form WordPress 2.0 tot 2.2. And what didn’t change?

Of course my theme was still the same, that wasn’t updated! Could there be somewhere an issue introduced?

Why was the SQL syntax truncated? It ended at FROM. Where was the tablename and the rest of the query?

Finding the solution

I decided to examine my theme files looking for the Links/Blogroll part and stumbled upon an query in the Links section in my sidebar.php. I opened phpMyAdmin and look for the table, it was not in the database! It seems that WordPress 2.2 joined a few tables, and referencing a non-existing table in a query will of course cause an error. This is the query:
< ?php $link_cats = $wpdb->get_results("SELECT cat_id, cat_name FROM $wpdb->linkcategories ");
foreach ($link_cats as $link_cat) {
?>

This table disappeared: linkcategories
A quick look into my database showed a table called: categories.

Fixing the code

I changed the code to:
< ?php $link_cats = $wpdb->get_results("SELECT cat_id, cat_name FROM $wpdb->categories");
foreach ($link_cats as $link_cat) {
?>

It helped, the error-message disappeared, but it showed a lot of empty categories. So i changed the code to:
< ?php $link_cats = $wpdb->get_results("SELECT cat_id, cat_name FROM $wpdb->categories where link_count > '0'");
foreach ($link_cats as $link_cat) {
?>

That was all. Now it’s working again!

Internet standard format (dotted string)

At first it doesn’t seem that dificult, most people simply store an IP-number as a string in their database tables. It simple and when you have a rather limited amount of addresses a simple VARCHAR 11 wil suit you rather well.
We all understand `192.168.1.10` and we use it everywhere, in our firewalls, routers and information about the internet.

Why not as long integer format?

But since an ip-address is a number, it can be stored much more effecient. In PHP there is a function ip2long that will convert an IPv4 Internet network address from its Internet standard format (dotted string) representation. The resulting integer requires only a third of the original space and furthermore look-ups and indexing will be faster.

$ip='192.168.1.10';
 echo ip2long($ip);

will output -1062731510

Note: Because PHP’s integer type is signed, and many IP addresses will result in negative integers, you need to use the “%u” formatter of sprintf() or printf() to get the string representation of the unsigned IP address.

So

$ip='192.168.1.10';
 echo ip2long($ip);
printf("%u\n", ip2long($ip));

results 3232235786 and this can be stored in an INT(11) field in MySQL.

To my surprise I did not get any negative number on my Linux server in the former example, this in contrast to my windows server. It seems that Linux 64 systems automatically converts the ip long address to the needed unsigned version, or more precisely integers on a 64 bit system are 64 bit instead of 32 bit so integers are not longer limited to 2147483647. I can’t confirm this on a Windows 64 bit system.

This means that we can cut the printf command, but for compatibility reasons I will leave it there, it will do no harm.

Converting to dotted string format

To function long2ip() will do the opposite and can be used to format a stored ip number in long format into a string in Internet standard dotted format for output on the screen. It doesn’t matter if the variable is an unsigned or signed integer:

echo long2ip(ip2long($ip));
echo long2ip(sprintf("%u\n", ip2long($ip)));

Will both print 192.168.1.10;

Converting with MySQL.

An alternative way and probably the most efficient is to let MySQL do the converting:

INET_ATON(expr) 

Given the dotted-quad representation of a network address as a string, returns an integer that represents the numeric value of the address. Addresses may be 4- or 8-byte addresses.

INSERT INTO `ip_addresses` INET_ATON('192.168.1.10');
 will store 3232235786

The generated number is always in network byte order. For the example just shown, the number is calculated as 192*256*256*256 + 168*256*256 + 1*256 + 10.

Retrieving the IP-number

The function to retrieve the ip-number in dotted string format is INET_NTOA()

SELECT INET_NTOA(3232235786);
will result '192.168.1.10'

The two functions were added in MySQL 3.23.15, so it can be used on nearly all systems.