Deactivating a WordPress Plugin Automatically

With every release of WordPress there are so many cool new features to play with. This usually a good thing but one downside is that if you want to incorporate them straightaway into your Plugin it can break versions of WordPress that haven’t upgraded yet.

I had exactly this issue when adding some new code to my Plugin Options Starter Kit Plugin.

I added two new text areas to the Plugin options form that use the built-in WordPress editor. This is made possible by the fantastic wp_editor() function, which is only available in WordPress 3.3 (see my post on this function here). However, a lot of users who are already running this Plugin may not have upgraded to WordPress 3.3 (when it is released) by the time I post the Plugin update on WordPress.org.

So where does this leave you? How can you safeguard against Plugin incompatibility with a users version of WordPress. You could insert a simple die() function, but we can do better than that!

Check out the code below that generates the above message, safely deactivates the incompatible Plugin, and provides a convenient link back to the WordPress admin.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function posk_requires_wordpress_version() {
	global $wp_version;
	$plugin = plugin_basename( __FILE__ );
	$plugin_data = get_plugin_data( __FILE__, false );
	$require_wp = "3.5";
 
	if ( version_compare( $wp_version, $require_wp, "<" ) ) {
		if( is_plugin_active($plugin) ) {
			deactivate_plugins( $plugin );
			wp_die( "<strong>".$plugin_data['Name']."</strong> requires <strong>WordPress ".$require_wp."</strong> or higher, and has been deactivated! Please upgrade WordPress and try again.<br /><br />Back to the WordPress <a href='".get_admin_url(null, 'plugins.php')."'>Plugins page</a>." );
		}
	}
}
add_action( 'admin_init', 'posk_requires_wordpress_version' );

So, what’s going on here?

First, we grab the current version of WordPress stored in the global $wp_version variable. Next, we have two lines of code to store the plugin folder/filename, and the name of the Plugin itself.

Now for the important bit. We use version_compare() to check we are running WordPress 3.3 or higher. If you want to check for a different version just change ‘3.3’ to a different value. If your installed version of WordPress is not compatible with the Plugin then we can go ahead and deactivate the Plugin, output a message, and halt the script.

Let’s check our Plugin is actually activated before we try to deactivate anything. We do this with the is_plugin_active() function. We need to pass in the Plugin folder and filename, which we stored in $plugin earlier. A value of true will be passed back if the Plugin is active.

Once we have confirmation that we can go ahead and deactivate our Plugin we just need to call the deactivate_plugins() function and pass it $plugin. This will actually deactivate the Plugin. The final step is to just call wp_die() with a suitable message. I have also added a link back to the WordPress admin for convenience.

You may be wondering why I am adding the code to a function and triggering it via the ‘admin_init’ action hook. Why not just add it outside of a function at the top of the Plugin file?

This is because of the is_plugin_active() function. If you try to call it outside of a function somewhere in your Plugin file, then it won’t have been defined by WordPress yet and a fatal ‘Call to undefined function’ error will be generated. This will also happen if you try to hook the function too early. Try replacing the ‘admin_init’ hook with ‘plugins_loaded’ instead to see what I mean. As long as you hook the function with ‘admin_init’ though everything should be fine.

The function is generic enough to be dropped into any existing Plugin and work right out of the box (neat huh?). The only thing you might need to adjust is the version of WordPress you want to test against.

I hope you find this code snippet useful. As usual let me know what you think in the comments.