Add Device-Specific Class Names To Body Tag


This is day 21 of my WordPress Developer Advent Calendar.

If you ever wanted to alter the body class on the frontend of a WordPress site, you would use the body_class filter:

add_filter( 'body_class', array( $this, 'add_class_names' ) );

I wanted to add device-specific class names onto the body tag, so that I could then target those classes in my stylesheets and javascript to change the way my site responds on different devices. Perhaps I want to show a popup for all visitors who are using IE. The applications are limitless.

WordPress already has built in global variables for which browser the visitor is using:

global $is_lynx, $is_gecko, $is_IE, $is_opera, $is_NS4, $is_safari, $is_chrome;

You can then use these variables and append class names by using the body_class filter:

function add_browser_class_names_to_body($classes) {
    global $is_lynx, $is_gecko, $is_IE, $is_opera, $is_NS4, $is_safari, $is_chrome;
    if ($is_lynx) { $classes[] = "lynx"; }
    if ($is_gecko) { $classes[] = "gecko"; }
    if ($is_opera) { $classes[] = "opera"; }
    if ($is_NS4) { $classes[] = "ns4"; }
    if ($is_safari) { $classes[] = "safari"; }
    if ($is_chrome) { $classes[] = "chrome"; }
    if ($is_IE) { $classes[] = "ie"; }
    return $classes;
add_filter( 'body_class', 'add_browser_class_names_to_body' );

What About Mobile Detection?

I wanted to take it a step further and also add classes based on the type of mobile device that was being used, e.g. iPhone, Android, Blackberry, etc. There is a great project on Github called MobileDetect which allows you to do just that. Here is a simple way to use the library:

$md = new Mobile_Detect();
if ( $md->isTablet() ) { 
    //do stuff for tablet
else if ( $md->isMobile() ) { 
    //do stuff for mobile
//Specific types of mobile devices
if ( $md->isIphone() ) { 
    //do stuff for iphone
if ( $md->isAndroidOS() ) {
    //do stuff for android

So combining that code and the body_class filter you can do some pretty cool stuff:

function add_mobile_class_names_to_body($classes) {
    $md = new Mobile_Detect();
    //Tablet, Mobile or Desktop
    if ( $md->isTablet() ) { $classes[] = 'tablet'; }
    else if ( $md->isMobile() ) { $classes[] = "mobile"; }
    else { $classes[] = "desktop"; }
    //Specific types of mobile devices
    if ( $md->isIphone() ) { $classes[] = 'iphone'; }
    if ( $md->isAndroidOS() ) { $classes[] = 'android'; }
    if ( $md->isBlackBerry() ) { $classes[] = 'blackberry'; }
    return $classes;
add_filter( 'body_class', 'add_mobile_class_names_to_body' );

A visitor browsing your site with an iPhone will get a body tag that looks similar to:

<body class="mobile iphone">

Bringing It All Together

I wrapped all of the above into a nifty little plugin which you can find on Github called Device Body Class. It automatically adds device specific class names onto the body tag. Classes it will add (if applicable) are:

  • tablet
  • mobile
  • desktop
  • iphone
  • ipad
  • android
  • blackberry
  • windows_mobile
  • samsung
  • kindle
  • lynx
  • gecko
  • opera
  • ns4
  • safari
  • chrome
  • ie

WordPress REST API

| 1 Comment

This is day 20 of my WordPress Developer Advent Calendar.

I love how all new major additions to WordPress core are being developed as plugins first, so that they can be tested and put through their paces. One of these plugins is WP-API, which gives your WordPress site a REST API. If you are unsure what REST is, then I suggest you read up on the topic first:

  • A Beginner’s Guide to HTTP and REST
  • What exactly is RESTful programming?

Make WordPress RESTful

To give this new feature a spin, this is what you need to do:

  1. Download the WP-API plugin and activate it on a local WP install.
  2. Make sure your permalinks are set to “post name”.
  3. Install the best API testing tool available : PostMan (this is a chrome extension).

Make Your First RESTful Request

Now that it is installed and running, open up Postman and do a GET request to:


Where http://local-wp-install is the location of your local WordPress environment. In my case it was http://wp/wp-json.php and you can see the result I got in PostMan:

WP-API First Request In Postman

The result you get back is a JSON document which includes all the RESTful URL’s or “routes” that you can now access in your very own API. Very cool. Now let’s get back all your posts. I did a GET request to http://wp/wp-json.php/posts, and the response was:

WP-API Posts

To get back a listing of all post types in your WordPress install, do a GET request to http://wp/wp-json.php/posts/types.

Now this is only the tip of the iceberg, and you can do a whole lot more with the API. For more detailed documentation, check out:

  • The Getting Started guide.
  • Working with Posts - how to retrieve, save, update and delete posts via the API.
  • Extending the API - really interesting for plugin authors.

Master The WordPress Cron


This is day 19 of my WordPress Developer Advent Calendar.

If you have ever worked with the WordPress Cron before, you know how difficult it is to test and debug. For those who do not know what the WordPress Cron is, in a nutshell, it allows you to schedule jobs/tasks to run at specific time intervals. Very handy indeed. For example, every week, you want to check for new users who have signed up to your blog and send them a thank you email.

Schedule Events

You call the wp_schedule_event function to setup jobs in the WordPress Cron. An example:

if ( ! wp_next_scheduled( 'send_flowers_to_mom' ) ) {
	wp_schedule_event( current_time( 'timestamp' ), 'weekly', 'send_flowers_to_mom' );

This first checks if the job exists, and then creates it if needed. I am not going to go into more detail than that. For a thorough walkthrough of scheduling jobs check out the very detailed post Schedule Events Using WordPress Cron.

Which Cron Jobs Are Active?

So how do you know which cron jobs are active, and more importantly, when will a certain job execute next? There are 2 plugins which can help. The one is a Debug Bar add-on plugin called Debug Bar Cron. This adds a new tab to the Debug Bar dashboard where you can see all active jobs and also see when they will be executed next:



The  other plugin I use is called WP Control. It allows you to view and control what is scheduled in the cron. It also allows you to add a job from the WP Control page in the admin. But my favourite feature is the ability to run any job right now. This is a great way to test your scheduled jobs:



Crons And Xdebug

If you use Xdebug to debug your WordPress code (and I highly recommend that you do!) then you will notice that when cron jobs are executed, you cannot step into your code to debug what is going on. The reason for this is the way that the WordPress cron executes these jobs. If you look at the code inside cron.php, you will notice it does the following:

wp_remote_post( $cron_request['url'], $cron_request['args'] );

You cannot debug code that is called via wp_remote_post, because for xdebug to work, you need to activate it by specifying a specific querystring or cookie. The only way to do this with wp_remote_post calls, is to intercept the calls and add a XDEBUG_SESSION cookie. I created a very simple little plugin that does just that. It is called XDebug Http Requests and the code is available on Github.

Master The Cron

With this combination of plugins, you will be able to:

  1. See which cron jobs are currently scheduled.
  2. Manually execute a specific job.
  3. Step into the code and debug what is actually happening.