How To Prevent WordPress Plugins From Activating On Sites With Incompatible Hosting Environments

It’s frustrating for plugin authors when users mark their plugin as broken when in fact, it’s an incompatibility with the user’s hosting environment. Too many broken plugin reports could damage the reputation of the author even if it’s not his/her fault. Pressing Matters proposed a solution to the problem that while good for developers, is not great for users.

Adding Two More Sections Of Data To The Plugin Header File

Their first request is for two additional sections of meta-information to be added to the plugin file header. This way, developers could specify the minimum PHP and MySQL requirements needed to successfully use the plugin. As a plugin user myself, I don’t like this method because I don’t think users should have to worry about what version of PHP or MySQL is running on their webhosting server. The plugin should either work or gracefully display an error message explaining why it won’t without causing the entire website to crash.

The second technique uses an explicit if statement to check whether the minimum system requirements are met. If not, a prompt would be displayed informing the user the plugin is incompatible and then ask the user to upgrade. The last part of this solution is confusing. What would the user need to upgrade? It’s not like they can upgrade PHP and MySQL versions on shared hosting servers.

Gary Pendergast Has A Better Way Of Accomplishing The Goal

WordPress Developer Gary Pendergast has a better way of accomplishing the same goal. Using the code in his post, plugins are only activated if a specific version of WordPress or higher is installed. With this technique, plugin authors maintain full control over when plugins are activated. If an incompatible version of WordPress is detected, a disabled notice will appear and the plugin remains deactivated.

Gary’s code snippet republished with permission:
[php]// In this example, only allow activation on WordPress 3.7 or higher
class MyPlugin {
function __construct() {
add_action( ‘admin_init’, array( $this, ‘check_version’ ) );

// Don’t run anything else in the plugin, if we’re on an incompatible WordPress version
if ( ! self::compatible_version() ) {
return;
}
}

// The primary sanity check, automatically disable the plugin on activation if it doesn’t
// meet minimum requirements.
static function activation_check() {
if ( ! self::compatible_version() ) {
deactivate_plugins( plugin_basename( __FILE__ ) );
wp_die( __( ‘My Plugin requires WordPress 3.7 or higher!’, ‘my-plugin’ ) );
}
}

// The backup sanity check, in case the plugin is activated in a weird way,
// or the versions change after activation.
function check_version() {
if ( ! self::compatible_version() ) {
if ( is_plugin_active( plugin_basename( __FILE__ ) ) ) {
deactivate_plugins( plugin_basename( __FILE__ ) );
add_action( ‘admin_notices’, array( $this, ‘disabled_notice’ ) );
if ( isset( $_GET[‘activate’] ) ) {
unset( $_GET[‘activate’] );
}
}
}
}

function disabled_notice() {
echo ‘<strong>’ . esc_html__( ‘My Plugin requires WordPress 3.7 or higher!’, ‘my-plugin’ ) . ‘</strong>’;
}

static function compatible_version() {
if ( version_compare( $GLOBALS[‘wp_version’], ‘3.7’, ‘<‘ ) ) {
return false;
}

// Add sanity checks for other version requirements here

return true;
}
}

global $myplugin;
$myplugin = new MyPlugin();

register_activation_hook( __FILE__, array( ‘MyPlugin’, ‘activation_check’ ) );
[/php]

According to Gary:

It’s only a little extra code when added to a plugin, provides complete protection, and won’t cause any weirdness on the front end of your site. It’ll just deactivate itself either on activation, or when someone visits wp-admin.

It’s a bit of code that can go a long way towards making sure users are not ambushed with a broken site when activating a plugin that is incompatible with their setup. If you know a better technique, I’d love to hear about it in the comments.