In a new tutorial posted to PHPMaster.com today, Lukas White talks about using the Browscap functionality to do server-side device/client detection in your applications.

An alternative solution to the problem is to use server-side device detection and then take certain actions based on that information. One possibility is to simply forward requests for a mobile site to a different URL. Another possibility is to adapt the layout – or indeed content – programmatically as it’s generated on the server. Taking a server-side approach is the basis of this article, which looks in detail at the Browser Capabilities Project, or Browscap for short, to provide the information on which to base these decisions.

He starts with some of the basics - User-Agent strings that most devices will send to your site and their structure. He then talks about the Browscap project and the PHP support for its use. He shows how to get it all installed via Composer and how to use the "browscap-php" library to get the current browser information. He includes an example of the output and shows how to use this to redirect the user to a mobile site if needed. He also adds in a bit at the end about using it for layout switching or for showing the user the correct download links based on their client.

David Walsh has a new post to his blog today with some code snippets that can help you detect iPad users when they come to your site.

The hottest device out there right now seems to be the iPad. iPad this, iPad that, iPod your mom. I'm underwhelmed with the device but that doesn't mean I shouldn't try to account for such devices on the websites I create.

He includes three ways to get the job done by matching against the User Agent sent by the browser - Javascript, PHP and with an .htaccess file for an Apache server. As one commenter points out, though, you need to be sure if you already have a redirect on the word "mobile", the iPad's User Agent contains that too.

Jonathan Street has a tip for those developers out there that have no other choice than scraping content from a remote site - don't make it obvious. He also includes a suggestion on how to make it a little less obvious.

A couple of hours ago I was playing around scraping some content from a website. All was going well until suddenly I couldn't get my script to fetch meaningful content. [...] The first thing I did was stop visiting the site for 15 minutes or so and then increase the time between requests. It briefly worked again but quickly stopped.

One simple change to his user agent string in his php.ini made the problem evaporate pointing to a user agent filtering happening on the remote side. His helpful hint involves two methods - one in just PHP and the other in cURL - to change the user agent that your scripts are sending. An even better sort of solution might be some sort of rotating array that would alternate between four or five strings to make things even more random.

Jonathan Street has a tip for those developers out there that have no other choice than scraping content from a remote site - don't make it obvious. He also includes a suggestion on how to make it a little less obvious.

A couple of hours ago I was playing around scraping some content from a website. All was going well until suddenly I couldn't get my script to fetch meaningful content. [...] The first thing I did was stop visiting the site for 15 minutes or so and then increase the time between requests. It briefly worked again but quickly stopped.

One simple change to his user agent string in his php.ini made the problem evaporate pointing to a user agent filtering happening on the remote side. His helpful hint involves two methods - one in just PHP and the other in cURL - to change the user agent that your scripts are sending. An even better sort of solution might be some sort of rotating array that would alternate between four or five strings to make things even more random.