How to limit WordPress’ compatibility, and why you should

Default avatar.
May 06, 2014
How to limit WordPress’ compatibility, and why you should.

thumbnailAs web designers, it goes against our nature to restrict access to our code. We're taught to maximize compatibility of our websites and strive for backwards compatibility wherever possible; to create progressively enhanced and gracefully degrading sites. If we can make it work on IE1, that's no bad thing…

The problem, at least for WordPress developers, is that WordPress is a monster; it will swallow you and your lovely little project whole if you let it.

When you're producing a WordPress theme, either as a bespoke job for a specific client, or to resell on one of the many WordPress marketplaces, your goal can never be to cover everything that has ever been part of WordPress. Instead, your goal should be to use the key functions, features and filters in the best way possible to maximize the current codebase.

As a professional, your time is money, the longer you spend on your development the less profit you make; it's a simple equation. The size of WordPress means that you can easily spend 80% of your time catering to 20% of the market. Far better to spend 80% of the time catering to 80% of the market. In terms of quality product and your own bank balance, it's the surest approach.

In 14 key WordPress functions to jump-start theme development we went through some of the functions that, without fail, I include in my starter theme's functions.php. In this article, we cover another crucial function that should go on your list of key WordPress functions. It will save you both head, and heart, aches down the road.

WordPress already limits backward compatibility

When an avoidable exploit brings your client's site (that runs on your theme) down to its knees, who do you think they'll call? Let me save you the guesswork: its you, m'kay? It doesn't matter that whatever's causing the problem isn't at all your fault, to the client, it only matters that you're the closest link to the possible problem. The last thing they remember doing is hiring you to build a new theme for them.

If upon inspection you find that the client's site still runs on WordPress older than the current stable version, take a few seconds and slap yourself across the face: left cheek first, then right cheek. Your theme should not allow them to do that!

If you've been paying attention, as of about Version 3.6 of WordPress, you'll have started to notice a function pretty high up in the default theme's functions.php that restricted use of the default theme to versions of WP newer than 3.6. In fact it's the second function defined in Twenty Fourteen's functions.php!

That function looks something like this:

/**
* Twenty Fourteen only works in WordPress 3.6 or later.
*/
if ( version_compare( $GLOBALS['wp_version'], '3.6', '<' ) ) {
 require get_template_directory() . '/inc/back-compat.php';
}

We're interest in the contents of that back-compat.php file. The functions defined there are what we're after for use with our own themes.

No country for old WordPress

It almost doesn't matter what features you're implementing but if possible, limit the use of your themes to reasonably new versions of WordPress. That'll make sure the end user updates their installation (all the better for them in terms of security) and ensures that you're spending the majority of your development time on the majority of users.

Defining the function

To achieve this, we use the PHP version_compare() function to check the currently installed version of WordPress against the latest available version making sure that the latest installed version isn't lower than 3.6—make your own selection on what version to test for, 3.6 isn't a recommendation, just an example. That function looks something like this:

if ( version_compare( $GLOBALS['wp_version'], '3.6', '<' ) ) {
 // do (or do not) something
 function butter_never_get_old() {
 switch_theme( WP_DEFAULT_THEME, WP_DEFAULT_THEME );
 unset( $_GET['activated'] );
 add_action( 'admin_notices', 'butter_step_your_game_up' ); // we add some admin notices here (we haven't defined this function yet)
 }
 add_action( 'after_switch_theme', 'butter_never_get_old' );
}

What this function does is define an action function butter_never_get_old() that will only run when the after_switch_theme() core function is called. So far, the butter_never_get_old() function, which sits inside our version check, does the following:

  1. Checks what version of WordPress is currently installed
  2. Makes sure that version is newer than Version 3.6
  3. Runs the cosmically relevant If/Else:
  4. If it is: Activate the theme.
  5. If it is not: Do not activate the theme. Instead re/activate the default theme and, to be nice, output a nice little message that instructs the user to upgrade their ridiculously old installation. Come on, Grandpa!

Nudge, nudge! Upgrade that s#%*

Next, we need to define the butter_step_your_game_up() function which prints out our admin notices if something should go awry which would ostensibly mean that the WP version is older than we'd like.

function butter_step_your_game_up() {
 $update_message = sprintf( __( 'This theme requires WordPress version 3.6 or newer. You're currently using version %s. Please upgrade.', 'butter' ), $GLOBALS['wp_version'] );
 printf( '<div class="error"><p>%s</p></div>', $update_message );
}

The above butter_step_your_game_up() function sets our translatable error message string in the $update_message variable as defined (this theme requires... etc) which is then printed and displayed to the user (from within the earlier defined butter_never_get_old() function ) and visually, inside a div with class of 'error'. This message, you can then style as desired.

So, all told, our function should look like this:

if ( version_compare( $GLOBALS['wp_version'], '3.6', '<' ) ) {
 // This function deactivates our newly activated theme if WP isn't newer than 3.6
 // It then re/activates the default theme
 function butter_never_get_old() {
 switch_theme( WP_DEFAULT_THEME, WP_DEFAULT_THEME );
 unset( $_GET['activated'] );
 add_action( 'admin_notices', 'butter_step_your_game_up' );
 }
 add_action( 'after_switch_theme', 'butter_never_get_old' );
 // This function, called from within the above function
 // outputs the relevant message that nudges the theme's user
 // to upgrade
 function butter_step_your_game_up() {
 $update_message = sprintf( __( 'This theme requires WordPress version 3.6 or newer. You are currently using version %s. Please upgrade!', 'butter' ), $GLOBALS['wp_version'] );
 printf( '<div class="error"><p>%s</p></div>', $update_message );
 }
}

With that in place, you're ensuring that your theme cannot be activated on WordPress installations older than version 3.6.

Keep it clean

As far as possible, you should keep your functions.php clean. It should be clean in the sense that you should be able to quickly scan and immediately discern what each function is doing. To that end, we might want to move our function into an includes folder.

If you haven't already, create a folder and name it 'inc' inside your theme’s directory. Inside that, create a php file and name that back-compat.php. Copy and paste the contents of the function we just created leaving only the version_compare() in functions.php:

if ( version_compare( $GLOBALS['wp_version'], '3.6', '<' ) ) {
 require get_template_directory() . '/inc/back-compat.php';
}

Inside the /inc/back-compat.php file, paste the functions we defined earlier:

function butter_never_get_old() {
 switch_theme( WP_DEFAULT_THEME, WP_DEFAULT_THEME );
 unset( $_GET['activated'] );
 add_action( 'admin_notices', 'butter_step_your_game_up' );
}
add_action( 'after_switch_theme', 'butter_never_get_old' );
function butter_step_your_game_up() {
 $update_message = sprintf( __( 'This theme requires WordPress version 3.6 or newer. You are currently using version %s. Please upgrade!', 'butter' ), $GLOBALS['wp_version'] );
 printf( '<div class="error"><p>%s</p></div>', $update_message );
}

Conclusion

It's always a tough sell to tell a good developer that they have to limit the compatibility of their code. But the sheer size of the WordPress codebase, especially when you focus on backwards compatibility, makes limiting the scope of your theme a practical necessity. WordPress themselves doing so should highlight its validity.

And now, freed from the constant obstacles presented by out of date code, you can focus your energies where they belong: on harnessing the awesome power of WordPress.

Featured image/thumbnail, uses compatibility image via Shutterstock.

Joe Nyaggah

Joe Nyaggah runs the independent design consultancy nyaggah.com based in Newport Beach, CA and specializing in brand identity design, web design & development. He also runs wpnom.com which helps theme designers simplify and streamline the WordPress theme design process. Follow Joe on Twitter here: @wpnom

Read Next

15 Best New Fonts, July 2024

Welcome to our monthly roundup of the best fonts we’ve found online in the last four weeks. This month, there are fewer…

20 Best New Websites, July 2024

Welcome to July’s round up of websites to inspire you. This month’s collection ranges from the most stripped-back…

Top 7 WordPress Plugins for 2024: Enhance Your Site's Performance

WordPress is a hands-down favorite of website designers and developers. Renowned for its flexibility and ease of use,…

Exciting New Tools for Designers, July 2024

Welcome to this July’s collection of tools, gathered from around the web over the past month. We hope you’ll find…

3 Essential Design Trends, July 2024

Add some summer sizzle to your design projects with trendy website elements. Learn what's trending and how to use these…

15 Best New Fonts, June 2024

Welcome to our roundup of the best new fonts we’ve found online in the last month. This month, there are notably fewer…

20 Best New Websites, June 2024

Arranging content in an easily accessible way is the backbone of any user-friendly website. A good website will present…

Exciting New Tools for Designers, June 2024

In this month’s roundup of the best tools for web designers and developers, we’ll explore a range of new and noteworthy…

3 Essential Design Trends, June 2024

Summer is off to a fun start with some highly dramatic website design trends showing up in projects. Let's dive in!

15 Best New Fonts, May 2024

In this month’s edition, there are lots of historically-inspired typefaces, more of the growing trend for French…

How to Reduce The Carbon Footprint of Your Website

On average, a web page produces 4.61 grams of CO2 for every page view; for whole sites, that amounts to hundreds of KG…

20 Best New Websites, May 2024

Welcome to May’s compilation of the best sites on the web. This month we’re focused on color for younger humans,…