There’s been a lot of chatter about how to handle the detection of the new dashboard design in a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. 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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. 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 PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.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