More than 4 years ago I developed the first library to parse WURFL. Initially it was only a PHP file that parsed the XML and created an associative array.

Later I added a class to also search a device given a user-agent and get capability values for the user-agent. With the growth of WURFL, caching was needed to try to speed up the search and retrival of data.

My WURFL PHP library has a very minimal set of requirements, PHP and XML support compiled in. This is something that I never wanted to change during these years to make sure that ANYONE could download and use it.

I am happy to announce that more development has been done on top of my original library and that Steve Kamerman, the author, has achieved great performance results with his new library.
The new library uses MySQL, so a new requirement is added. For this reason I will keep my library as-is, but still, if you have a database available and want some good performances, then I suggest you take a look at Tera-WURFL.

It’s worth visiting the links presented below to see it in action.
There is a test page that lets you see how user-agents are matched and some speed test.
Also, since Tera-WURFL uses a database you will need to update it when a new XML comes. Steve provides a nice admin panel to manage the script and data (don’t mess up with it too much!).

So, once again, congratulations to Steve for his huge work and great new library.

PHP 5 penetration

A couple of days ago I met with Julien. We talked about many things, among which, PHP. I remember talking with him about PHP 5 about a year ago, so I asked if he has started doing any work with it as I haven’t even tried it since it came out. He told me that he hasn’t ever used it for a real project.

Not that I read hardcore PHP developers forums, but I have heard of very few developers using it. We started wondering about the success of PHP 5 and why developers should move from version 4.

The conclusion was that probably PHP 5 did not introduce those features that make a developer move from a major version to another.

Today Julien sent me a report about PHP 4 and 5 usage, installed versions and so on. Take a look and you will see that servers running PHP 5 are still a big minority even if it has been released in July 2004!.

Seems like a big failure.

WURFL Patch debugging

The ability of applying your own patches, modifications and updates to WURFL is really important. If you are here reading the post then you probably have already visited the WURFL site and read about the patch file. If you haven’t this is a good time!

As the WURFL evolves and as we add new devices, it is obvious that you might find some conflicts applying your patch file OR it might happen that you patch file is not applied properly.
Something that happened to me just a few days ago (and I actually hit my head on the wall for a while before understanding why) was that we slightly changed the fall_back tree for the SonyEricsson S700 “family”. First of all, why do I say family? That’s because many recent SonyEricsson devices are all the same and change their name slightly depending on the area. For example the S700i is the same as the S700a, the former is sold in Europe, the latter in North America and they are the same as the S700c which is sold in China.
For this reason we have created a “virtual device” so not an actual_device called S700 and then configured the S700i, S700a and S700c to fall_back on it. The fall_back was changed from sonyericsson_401_generic to sonyericsson_s700_ver1 and all capabilities such as screen size and image formats were moved for the S700i to the “generic S700”.

Unfortunately in my patch file I was add some information about the S700i and I was automatically changing the fall_back from to the old one. This way I basically still got my “new capability” but LOST all the device capabilities such as the screen size!
This was really disappointing!

How to verify your patch file?
I just committed to CVS an update to the PHP library. In the wurfl_config.php there’s a new constant called “WURFL_PATCH_DEBUG“, it’s a boolean. By default it’s set to false, but if you need to check your patch file you should change it to true.
When set to true, when applying the patch, the library will generate A TON of logs, but really useful to track changes and updates.
This is an example of what you get:

Fri, 3 Mar 2006 14:46:04 +0100 [Enlighted 1599][parse] Updating device nokia_3220_ver1
Fri, 3 Mar 2006 14:46:04 +0100 [Enlighted 1599][parse] nokia_3220_ver1: setting themes_nokia_s40=1

As you can see, now I can check which devices were updated. I also see if a device was added and of course what was added or updated. In this case I configured that the device supports Themes for the Nokia Series 40.

Now let’s see what it says about the S700:

Fri, 3 Mar 2006 14:46:05 +0100 [Enlighted 1599][parse] Updating device sonyericsson_s700i_ver1 : fall_back, sonyericsson_s700_ver1=>sonyericsson_401_generic,

As you can see it says that the device was changed and that the fall_back has been updated. In most cases you will be happy about this change and you probably made a patch JUST for this. In cases like mine you will not be as happy.

The PHP library also logs any error in the patch file. When turning the debug on you will also get some extra information that should help you understand why the update failed.

Happy patching, then!