Targeting the new dashboard design in a post-MP6 world

There’s been a lot of chatter about how to handle the detection of the new dashboard design in a plugin in WordPress 3.8, now that the “mp6” body class is gone. I have three suggestions, any of which can be used depending on the situation.

The WordPress admin assigns a “branch-x-y” class to the body. So, branch-3-8, branch-3-9, etc. But rather than targeting 3.8 or newer this way (which will require you to add selectors for versions far into the future), target 3.7 or older. So if the latest version of your plugin supports 3.6 or later:

[css]
.branch-3-6 .some-selector,
.branch-3-7 .some-selector {
/* some rules go here for 3.6 and 3.7 */
}
.some-selector {
/* 3.8+ rules go here */
}
[/css]

As your minimum requirements increase over time, the older rules can simply be removed. Pretty easy.

The second method is for when you require greater UI robustness. (This is also good for instant compatibility with existing code written against MP6.) Simply add your own mp6 class to the admin. The admin_body_class filter is a little funky, so bear with me:

[php]
add_filter( ‘admin_body_class’, ‘nacin_please_prefix_this_add_mp6_class’ );
function nacin_please_prefix_this_add_mp6_class( $classes ) {
if ( version_compare( $GLOBALS[‘wp_version’], ‘3.8-alpha’, ‘>’ ) ) {
$classes = explode( " ", $classes );
if ( ! in_array( ‘mp6’, $classes ) ) {
$classes[] = ‘mp6’;
}
$classes = implode( " ", $classes );
}
return $classes;
}
[/php]

An added benefit here is some nice standardization: If multiple plugins need this same class, it’ll simply be added once and be subject to shared usage.

The final method is for if you need to know in PHP whether MP6 the plugin is enabled outside the body class. For that, simply use the version_compare() above.

[php]
if ( version_compare( $GLOBALS[‘wp_version’], ‘3.8-alpha’, ‘>’ ) ) {
// 3.8 dashboard theme
}
[/php]

To those asking why we shouldn’t just include the class in 3.8: WordPress evolves over time, and even 3.8 has significant changes when compared to MP6 the plugin. While we do strive to maintain backwards compatibility — including, to some extent, when we merge in popular plugins — a line needs to be drawn somewhere. Short of introducing a “version” string of the UI (which would be redundant, given WP versions), there’s just no great way to solve this, especially when trying to be forwards compatible with future design changes (to 3.8 and beyond). It’s worth noting that the branch-x-y classes were introduced a few versions ago specifically for the purposes of managing UI changes in plugins.

A side note, and this is purely a personal preference, I’d really like to *stop* calling the dashboard design “MP6”. I don’t just mean in code, I also mean in general nomenclature and bug reports. Code names are cute in software development, and it helps to have a shorthand. (We already have a lot of them — too many, even.) But we’ve reached the point where we are about to ship this to tens of millions of users. It’s time to drop it. In bug reports, let’s simply set the “version” field to “trunk” and file it under the Administration component. In general, let’s celebrate it as the new design and aesthetic that WordPress 3.8 brings/brought us. It’s no longer MP6. It’s now just WordPress.

#mp6