Server-side mobile detection with caching?

[evanmcd]

Hi,

I've come across this issue for the first time and am wondering if anyone else has a better solution than what I've come up with.

I have a site that uses PHP to sniff the user agent and redirect if it finds one that matches with mobile.  Like this:

    $iphone = strpos($_SERVER['HTTP_USER_AGENT'],"iPhone");
    $ipad = strpos($_SERVER['HTTP_USER_AGENT'],"iPad");
    $ipod = strpos($_SERVER['HTTP_USER_AGENT'],"iPod");
    $winmo = strpos($_SERVER['HTTP_USER_AGENT'],"Windows Phone");
    $opera_mini = strpos($_SERVER['HTTP_USER_AGENT'],"Opera Mini");
    $android_mobile = false;

    if(stripos($_SERVER['HTTP_USER_AGENT'],"Android") && stripos($_SERVER['HTTP_USER_AGENT'],"mobile")){
        $android_mobile = true;
    }

    $is_mobile = 0;
    if($iphone || $ipod || $android_mobile || $winmo || $opera_mini) {
        $is_mobile = 1;
    }

    $is_ipad = 0;
    if($ipad) {
        $is_ipad = 1;
    }

    if($is_mobile) {
        header("location: m/");
    }

However, I'd like to use caching on templates that have this detection and have found (not surprisingly of course) that the redirection doesn't happen when caching is enabled - everyone gets served the desktop content.

I could use a JavaScript based solution, but that would not be ideal as part of the page would render before the user would be redirected.

Just wondering if anybody has any other ways to solve this problem.

Would ProCache solve this?

Thanks.

[alan]

If is JS, so maybe of ho help, but I have used this before:

if (Modernizr.touch) {   
    alert('Touch Screen');  
} else {   
    // alert('No Touch Screen');  
}

Written in jQuery (in case that matters) and therefore assumes jQ is loaded. Also requires http://modernizr.com/

Of course this detects for tablets too (and for the MS tablet that has trackpad and keyboard I think).

[Can]

Maybe this one helps

https://processwire.com/talk/topic/7-new-markupcache-module/

[Martijn Geerts]

There must be a good reason to use server-side sniffing. Until now I didn't come across a reason for this. I do think available space should be more important than the device. If you're on a mobile and link to a page that only exists on desktop do you show them a 404? And when you're on desktop but set the browser width to 400 you still want to show the desktop version?

Oke, I'll stop complaining... URL segments are cachable to, so maybe you can accomplish this with those.

[horst]

This post explain how I have solved an issue with serverside sniffing and ProCache. https://processwire.com/talk/topic/5349-how-can-i-bypass-the-cache-for-mobile-and-tablet-devices/#entry51544

(I came up to use clientside sniffing, but maybe you can use a combination of serverside and clientside, if you really need)

...

I use this code to check if it is a phone or tablet device and if yes, add the appropriate css class to the body tag:

var md = new MobileDetect(window.navigator.userAgent);
if(md.phone()) {
	document.body.className += (' mobile');
}
if(md.tablet()) {
	document.body.className += (' tablet');
}

The code is called directly after the opening body-tag and it seems to work without flickering or something that like. Also jquery isn't needed, or it isn't needed to load it before the content.

I do not add the class names to the body tag at serverside. So there do not exist different variations of one URL anymore. (To get this at 100%, I have to do some more tweaks in the template files, but this is the way to go)

For me it was the best solution to have (only) one cached file for all devices.

Edited May 13, 2014 by horst

[evanmcd]

Thanks for the responses everyone.  Perhaps I wasn't clear enough in my question.

Following the server-side detection, I'm redirecting mobile users to an entirely different page.  It's not a responsive page for which we are changing the display or structure of the same content on a single page.

After thinking about it for a bit, I will say that easy server-side caching is now another pro for a responsive design, but for now the desktop and mobile experiences are different pages.

I'll reply back here if/when I come up with a good solution.