Me and the boys at DealerTrend have been trying to provide a scalable solution for mobile sites to our clients. We’d experimented with the many plugins available in the WordPress repository and most of them made the following mistakes.

• Do all the running all the logic server side, which means caching is no longer possible via a proxy server.
• Rendering the new content under the same domain. In essence restructuring an entire sites markup and outputting the new content. This could be seen as duplication within the same product.
• Use static formulas for user agent detection.

Let’s take a look at the reasons I think these are mistakes.

First, running the logic on the server side produces an outcome…if that outcome is cached then someone else will see that outcome even if it doesn’t fit their situation. This means you can’t cache from an external server, it has to be done at the object level within WordPress. Which may not be ideal given that WordPress is using MySQL and in some cases, Apache which can only handle a (relatively) small load.

For high traffic sites, caching is a must.

Rendering a completely new layout for a specific use case and not changing the location seems like a horrible idea. Consider every domain a product, self contained with a primary subject. If you change the product on the fly without letting search engines know that the context has changed you will no doubt be shooting yourself in the foot. It’s best to use a subdomain, subfolder or some identifier to declare “Yo dawg, we’re showing the mobile view.”

You wouldn’t show your site mydomain.com with one layout and then if google reader hits it, completely change how it displays right? If you said “Yeah, why not?”, then slap yourself. You should redirect them to an RSS feed or a path that’s dedicated to handling that rendered view.

Context matters and so does location.

Lastly, many people use bloated static regular expressions for determining whether or not the UserAgent of the browser is, in fact, mobile. Which means, as new mobile devices hit the market OR as users of those mobile devices install new browsers, the owner of the plugin will need to continuously send out updates to his previous formula in order to keep up.

That’s AWESOME! That’s like every time someone updates their status on Facebook, an employee has to go in and manually add the new status to each of their friends page! If they don’t have time to do it, the user can just suck it up!

Constantly evolving data should not be encapsulated within a plugin. It should be a service.

So what did we do? Well we did some digging and found the guys over at www.handsetdetection.com

We did the trial, liked what we saw and started playing with it.

We decided to host a server dedicated to rendering mobile views and just send mobile users to that server whilst providing them a way to get back to the main site.

Here’s some Javascript that I wrote up to do that:

(function () {
    'use strict';

    var head, script, siteid, domain, internal, mobilesite;

    siteid = 123456;
    domain = new RegExp('mydomain.com', 'i');
    mobilesite = 'http://m.mydomain.com';

    head = document.getElementsByTagName('head')[0];
    script = document.createElement('script');
    internal = document.referrer.search(domain);

    script.type = 'text/javascript';
    script.src = 'http://api.handsetdetection.com/sites/js/' + siteid + '.js';

    if (internal === -1) {
        head.appendChild(script);
    }

    script.onload = function () {
        if (HandsetDetection.ismobile === true) {
            document.location = mobilesite;
        }
    };
}());

So basically what this does is after putting in the main sites url, the mobile url and the ID for the mobile detection script, it checks if the user is coming from an internal page (it treats the mobile view as an internal page) and if they are, it doesn’t try to redirect them to the mobile view. But if they come directly to the site or from a search engine, or other, it will shoot them over to mobile. Then at the bottom of the mobile view they can click the View Full Site link to get back to the main domain.

In order to not bloat our API requests, because there is a quota, we decided to only load the Javascript file if it was needed. So the script sees that it will need the Javascript file and appends it to the sites head element. Then after the external script is loaded, it runs through and if the site is mobile it redirects.

It was short, sweet and simple – a bit of fun.

Here’s a link to the gist if you need something to play with: https://gist.github.com/1245942