Top posts
Posts in Webdevelopment
PHP and browser detection
(No Ratings Yet)
Loading ...One of the things you might encounter as a web developer is detection of the browser that a visitor is using. In my specific case this was needed since I wanted to use some CSS3 styling, but only if the browser was capable. In all other cases the visitor had to see the CSS2 optimized page.
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.
Testing for mobile devices
As you might know this blog is also available through an own developed mobile edition, at http://m.narnio.com. It’s based on a plugin that I developed. But how do you go about with the testing for mobile platforms, when you don’t have all of them.
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:
- 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)
New WordPress skin, Ajax loading vs. Google
As a major remodeling of this blog is on the way I’m going to try to build it more dynamic and more up to the Web 2.0 standards. So that includes usage of Ajax, JQuery and a more dynamically filled website. But how to build this and keep the Google Analytics working, as well as the search engine indexing. This will be one of my biggest challenges I’m afraid.
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.
Working on a new layout
It’s been some time since my last post here, and there are several very good reasons for that. I’m currently rather busy trying to rebuild the skin for this blog, as well as several other development projects I’ve got going on right now. One might say I’m taking on more work then I can handle, but I love to be busy I guess. So what am I working on, and what can you be expecting in the time to come here:
- 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.
IE framesets and printing
So I recently encountered a weird problem with printing in Internet Explorer. To ease the usability of a website we opened a new window that had a frame-set in it with 2 frames. The first frame contained a button to close the pop up and the second frame a clone of the page to be printed. This was done to apply a slightly different lay-out to the print version.
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">
