Limit backward compatibility of your WordPress theme

Approach any WordPress solution with the same ferocity designers approach the browser wars: be reasonable but also unmistakably ruthless!

WordPress development seems to happen briskly and is applaudably fast. If, lets say, you’re a freelance front-end developer working in different languages and building across different platforms for your various clients and projects, by the time you find yourself back to a WordPress project, you’ll usually need a quick refresher.

You might be able to skate through the point releases but, it seems, with every full release you’ll need a decent re-schooling. Normally all you have to do is visit the codex and read up on what has been written since you’ve been gone; what new standards have been introduced, etc.

Beyond that though, you should approach any WordPress solution with the same ferocity designers approach the browser wars: be reasonable but also ruthless!

With each full release, WordPress implements features that are not supported in older versions. Unless your clients update their installation to the latest WP version, the awesomeness of the new features is lost on them.

From a theme designer’s standpoint, if you can rid yourself of pointless conditionals that check to see if certain features of WordPress are plausible in the currently operating version of the software, you’d be well on your way to DRY heaven.

Also, if you’re in a marketplace situation, where you have no understanding of what the eventual user’s installation looks like or is capable of, you have to start taking some precautions. You have to write brutally opinionated code.

As a designer, you understand this tactic. Its a PR move. 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. On the other hand, newer — at least in the WordPress world — is usually better. Newer features are usually quite beneficial. The implementation of new features, especially where roundabout ways have finally been packed nicely into a core function are so, so awesome!

Limit your support

If you’ve been paying attention, as of about Version 3.6, you started to notice a call, pretty high up in the functions.php that restricted use of the default theme in any version of WP that wasn’t newer than 3.6.

It almost doesn’t matter what features you’re implementing now but if possible, limit the use of whatever theme you’re building to a reasonably newer version of WordPress. That’ll make sure the end user updates their installation (all the better for them in terms of safety) and allows for them and you to take advantage of all the new functions/features.

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. That functions looks something like this:

if ( version_compare( $GLOBALS['wp_version'], '3.6', '<' ) ) {
  // do (or do not) something
}

This isn’t of much use if all we want to do is figure out if the currently installed version of WP is lesser than 3.6. Naturally, we DO want to check that but then once we have our TRUE/FALSE feedback, we go ahead and do something.

Assuming that a default theme exists, in our case, we want to test that the version of WP is greater than 3.6 and if not, ignore the users attempt to activate our new theme and revert (unset) to the theme that was previously defined.

What we want to do is make sure our theme absolutely does not activate in versions of WordPress lesser than 3.6. If a user tries to activate it, we want WordPress to revert back to the usually functional default theme and maybe also output a message informing the user that this new, beautiful, feature-packed theme is only functional in current versions of WordPress.

Do (or do not) something

We already started the WordPress version check. Now we do/not something.

So, inside our original version check, we define a function that does what we need it to do, which, in a few steps is:

  1. Check what version of WordPress is currently installed
  2. Make sure that version is newer than version #3.6
  3. The cosmically relevant If/Else:
    1. If it is: Activate the theme.
    2. 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.
function butter_never_get_old() {
  switch_theme( WP_DEFAULT_THEME, WP_DEFAULT_THEME );
  unset( $_GET['activated'] );
  // we add some admin notices here (we haven't defined this function yet)
  add_action( 'admin_notices', 'butter_step_your_game_up' );
}
add_action( 'after_switch_theme', 'butter_never_get_old' );

With this, what you’re doing is defining an action function butter_never_get_old() that will only run when the after_switch_theme() core function is called. Remember though, that this function goes inside your original version check functions so the code in your functions.php so far should look like this:

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

So, after checking the currently installed version of WP is no older than 3.6 we run the function butter_never_get_old(). If this functions finds that the version of WP is, in fact, older than that, it rejects the attempt to activate the theme and re/activates the WP_DEFAULT_THEME. In addition, it adds an admin notice that is defined by the butter_step_your_game_up() function that you haven’t defined yet.

Before we define the butter_step_your_game_up() function, you should be aware of something:

Step your game up

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”. You can then target that error div and style it as desired.

With that in place, you make sure that your theme cannot be activated on WordPress installations running Version 3.6 or older.

Divide and conquer

While the Theme Customizer was introduces in WordPress 3.4, you’ll notice that the latest version of WordPress default theme (Twenty Fourteen) just wholesale refuses to activate on older than 3.6 version installations. It issues a polite notice suggesting you upgrade to the latest WP version if you try to activate it. This and the live-preview features are explicitly disallowed through functions nested in the version_compare() function we saw earlier.

Simply put, while you don’t have to be exceedingly heavy-handed with what version of WordPress you support, make sure that your theme doesn’t have any if ( function_exists() ) conditional wrappers. In other words, DO NOT offer support for new core features to old versions of WordPress. Instead, instruct the user to update their installation.

The way to keep WordPress evolving and you remaining sane is to make sure the themes you put out there (and have to support for some time) do not get outdated and unusable.