So I started looking into a way to let my web application determine what browser was visiting and what capabilities it had. Since this was for the new WordPress theme I’m developing it had to be in PHP and be sorta light-weight.

First thing was to figure out the basic browser that was visiting. This can be done by doing a simple strpos call in PHP on the user agent property. Having a list of the various user agents helped, I found just such a list at UserAgentString. A brief summary for some common browsers is below.

  $user_agent = $_SERVER['HTTP_USER_AGENT'];
  $IE        = strpos($this->_user_agent, 'MSIE') > -1;
  $IPad      = strpos($this->_user_agent, 'iPad') > -1;
  $Firefox   = strpos($this->_user_agent, 'Firefox/') > -1;
  $Chrome    = strpos($this->_user_agent, 'Chrome/') > -1;
  $Opera     = strpos($this->_user_agent, 'Opera/') > -1;
  $Android = strpos($this->_user_agent, 'Android') > -1;

As you can see determining the basic browser type is pretty simple. But to be able to determine if CSS3 is supported you will also need to locate the version of the browser. Keeping in mind that IE9+, Firefox 4+, Opera 10+ and Chrome are the only versions that support CSS3. The check for this is slightly different for each version. But you can do it easily with a regular expresion.

 // For all non IE browsers
 $locator;
 if ($Firefox) $locator = "Firefox\/";
 if ($Android) $locator = "Android\s";
 if ($Chrome) $locator = "Chrome\/";
 if ($Opera) $locator = "Version\/";
 preg_match('/'.$locator.'([0-9]{1,4}(.[0-9]{1,3})+)/', $user_agent, $version);

 // For IE
 preg_match('/MSIE\s([0-9]{1,2}.[0-9]{1,2})/', $user_agent, $version);
 if (count($version) > 1) $version = $version[1];
 else $version = 0;

Having the version and the type of browser allows us to do all kinds of fancy browser specific stuff. Mostly introduce hacks for IE7 (yes many are needed), or add CSS3 support.

I mean who has the money to buy every possible phone out there, or every tablet.  Well there are some ways to do this without having all of the devices. Here is a short list:

• Run it through the validator at http://validator.w3.org/mobile/
• Use a simulator for testing like:
  • iPhoney, for iPhone testing
  • iBBDemo2, for iPad testing
• Doing a simple resolution check, for IE this can be done by hitting F12 and selecting Tools -> Resize
• Checking the load times on different connection speeds, using Fiddler 2 by changing Rules -> Performance -> Simulate modem speeds

So what are resolutions to check for with mobile devices, well here is a short list.

• 480 x 800 (default Android 1.5 – 2.2)
• 540 x 960 (newer Android phones 2.3.3)
• 640 x 960 (iPhone4)
• 1280 x 800 (various Android 3 tablets)

Developing a website with JQuery / Ajax and advanced JavaScript prototypes isn’t anything new to me. But having all of these features and still make the site indexable is! So far I’m stuck at the simple point that crawlers don’t support JavaScript, so no go for that part. It looks like I will have to create a module for the WordPress plugin to detect what type of user is visiting the website. Serving the search engines a version that will not use any of the advanced features that normal browsers will support.

Besides the issue with the indexing there is still the task of getting all the pages on the website to be tracked with Google Analytics. Currently that is easy, though the website is dynamic each page is a new request to the server. But using advanced features like Ajax stops that in its tracks. Currently I don’t even know if it is possible to track pages when the actual URL doesn’t change, just the content of the page. If it is possible to do this I would have to build a module to do so.

So after just ranting and brain storming for a few seconds I already found to nice features that would have to be build. Another person might call them serious issues, but I prefer good challenges. At least for the moment I do. Not even mentioning the fact that I have to build a complete new template for WordPress too.

• Redesigning this blog, to bring it up to speed with the latest possibilities from WordPress
• Building of the UML Design tool that I started on some months ago
• Defining the specs of a neural algorithm to build a user centric database (more on this to come in the future here)
• Continued development on the Synchronizer tool, hoping to release version 3.0 soon

And that’s just the work that I do in my rare spare time next to a full-time job.

For some reason some of our customers reported that the print-out font size was bigger then it was supposed to be. And in some cases the tables didn’t even fit the page anymore. Surprisingly everything worked normally in Firefox, and only the customers using IE7 and above reported the issue.

After a couple of hours debugging it turned out that IE jumped into some weird rendering mode that caused the content not to fit a normal A4 page anymore. Appearantly adding the DOCTYPE definition to set it to compatability mode helped solving the problem. So I included the below to fix the issue:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

As this plugin will require a bit more work then the combobox I have no idea as to when I can release a first usable version. But as soon as I do I will publish it here .

Initially I thought that this was caused by the plugin I use for this called NextGen Gallery. After all this plugin failed to do its job properly, but unfortunately that was a bit stupid thinking on my part. I should have realised that the plugin stopped working after an upgrade of the WordPress blog powering the website. For some reason the thickbox JQuery extension produced JavaScript exceptions.

I don’t know exactly why it doesn’t work like expected and I don’t really care either. Suffice it to say that changing a small piece of code in the ‘wp-includes/js/thickbox/thickbox.js’ fixed the issue. All I had to do is modify the tb_init function into the following:

function tb_init(domChunk)
{
     jQuery(domChunk).bind("click", tb_click);
}

I think it must have been some conflict in the JQuery versions or something, since it used to call the ‘.live‘ method on JQuery. But this was what was causing the exceptions. If anyone knows a more permanent fix for this issue please let me know.

As it turns out the autoloader functionality is called when PHP is unable to find the class you are using automatically itself as a last effort. Though that wasn't the issue I encountered. It took me about 3 hours of debugging the function to find out there was a problem with the logic of the autoloader function I wrote myself, doh!

Something with breaking out of a loop to early . After fixing this issue my autoloader was working beautifully. So I am happy to say that it is possible to write a modular PHP web application after all.

This first version includes:

1. Custom drop down arrows for disabled / mouse over and default combobox states
2. Ability to change the border styles of the drop down part as well as the combobox itself
3. Supports translating the following elements in comboboxes:
   1. select element
   2. ul & ol element

Please note: as this is the first release there may still be some bugs in the code, please feel free to contact me if you find any and I will attempt to solve them as quickly as possible.

Of course you could include every single file that you might need manually at the top of your index.php. But what if you don't need every single class every time a page is loaded, do you really want to create that kind of an overhead in loading un-needed files? I didn't, so I started looking into the autoloader functionality of PHP. What this feature does is allow you to scan through files in the predefined include directories and attempts to locate the class.

So what I did was build a simple autoloader function to scan each file in predefined directories to find the classes, and if found to stop. To my surprise this was working rather well. All classes that where needed would automatically get loaded by my little autoloader function. However somehow one particular class was not able to be loaded for some reason. The setup was something simple, something like:

• A predefined class A
• A class B which extended class A
• A class C which extended class B
• A class D which extended class C, and was located in a separate directory as it was specific for the website

All of the classes loaded beautifully, except for class D. For some reason when I tried using it I got exceptions that class C was undefined. When I added some debugging to find out which files where loaded I did see every file for classes A, B and C being loaded, but the actual classes defined inside where not added to PHP. Somehow I have magically created a black whole in PHP that would include files and then forget to create the class definitions internally. To this day I still haven't figured out why PHP refused to store the actual classes in its memory.

The quick fix I applied was ugly and stupid, just manually load the classes and build a big if statement around them to prevent duplicate declarations using the class_exists function.