I have a plugin distributed on WordPress.org that is fairly popular. I have to drop support for PHP 5.2and I'd like to at least drop support for PHP 5.2, but if I could make the minimum PHP 5.4, late static bindings and useful closures, would be great.

Before you say PHP7, keep in mind that plugin only has 100,000+ sites running it. For all WordPress sites, 10% fo sites are on PHP 5.3 or below. I am not risking breaking 10k sites.

We will be adding a PHP minimum version header, but this does not, on a programatic level, do anything yet.

I am looking for the right pattern to consistently short-circuit updates of my plugin unless the PHP version requirement is set. Does anyone have a bullet-proof way of doing this?

3 Answers 3


At this time, this is not possible. Not without the PHP minimum version header being implemented.

When that is done, then it will be possible. Until then, you cannot DIY through plugin code alone.

In theory, you could release an update that would block future updates for that one plugin if the PHP version wasn't met, but even then that would not prevent your plugin from receiving updates when it was not active. So, can't be done because plugin updates are done by WordPress, not by the plugins themselves.

  • But if the plugin isn't active, the updates won't cause a problem until it's activated. Right? So couldn't he use the plugin activation hook with only 5.2 code, check the version, and if it's not compatible deactivate the plugin with an admin notice? Mar 7, 2018 at 22:05
  • 2
    Doing it yourself is a bit premature when active work is being done to both add such a check to core, as well as to possibly modify the APIs to prevent incompatible updates from being sent to users. This is a problem that is actively being worked on, no need to jump the gun. :)
    – Otto
    Mar 7, 2018 at 22:17

F**k the Luddites ;)

While not directly answering the question, my own experience of moving a semi popular plugin from 5.2 to 5.3 is that there is much less friction than you might expect from looking at the wordpress.org usage stats, and those frictions are usually easily handled by the site owners.

And of course people that do direct changes on production sites, just deserve whatever they get ;)

In a way, unless you can show a prominent notice about the incompatibility, you are hurting the users more then helping them, as without such a notice they have no way to get an incentive to upgrade their server enviroment, and will not know they will never get new features or security updates.


I think it can be done.

I use this process to check for minimum version on plugin activation. You can use a variation on this to check during an upgrade (although I think an upgrade to a new version that contained this code would cause the plugin to deactivate).

The code to check minimum versions:

function is_requirements_met()
    $min_wp = '4.6' ; // minimum WP version
    $min_php = '5.3' ; // minimum PHP version
    // Check for WordPress version
    if ( version_compare( get_bloginfo('version'), $min_wp, '<' ))
        return false ;
    // Check the PHP version
    if ( version_compare(PHP_VERSION, $min_php, '<'))
        return false ;
    return true ;

.... and then this to disable the plugin if the versions don't match the requirements (function returned false)

if ( is_plugin_active( plugin_basename(__FILE__)))
        deactivate_plugins( plugin_basename(__FILE__)) ;
        // Hide the default "Plugin activated" notice
        if ( isset ($_GET['activate']))
            unset ($_GET['activate']) ;

Then I display an admin message to let them know the plugin was disabled:

add_action('admin_notices', 'show_notice') ;

Where the show_notice function displays a dismissable admin notice.

function show_notice()
    echo '<div class="notice notice-error is-dismissible"><h3><strong>Plugin </strong></h3><p> cannot be activated - requires at least WordPress 4.6 and PHP 5.3.&nbsp;&nbsp;&nbsp;Plugin automatically deactivated.</p></div>' ;
    return ;

Works just fine.

Edited to add

What if you put code in your plugin to block the plugin upgrade (something like this: https://stackoverflow.com/questions/17897044/wordpress-how-to-disable-plugin-update ).

The new version of the plugin has a pre-load stub. It will do a check for PHP version. If OK, load the rest of the plugin. If not, don't load the rest of the plugin. Code in pre-load stub will work in all PHP versions.

The pre-stub doesn't contain any PHP 7x code, so preprocessing the stub will not cause an error. The pre-stub will also disable the plugin using something similar to my original answer.

If PHP version is 7x, then pre-load stub loads the rest of the plugin. And Bob's your uncle.

  • if the plugin is written (for the sake of the argument) in PHP 7.2, utilizing the new language features, it is more likely to crash the site before emitting any notice. If you are going that way you should die on activation, but than again, activation hook is not executed at all on plugin upgrade. Mar 8, 2018 at 6:19
  • Which part of my sample code is 'likely to crash the site before emitting any notice'? Note that these are just code fragments, they don't show what part of the plugin code they are in. I will agree that they messages aren't written for multiple languages. And I did mention that I wasn't sure if the code would be called on an upgrade, and that a 'variation of the code might be used to check during an upgrade'. Mar 9, 2018 at 0:01
  • ...and although the code may not be run during an upgrade, I believe it will be run on the next admin page load. Mar 9, 2018 at 1:37
  • your code do not need to crash, but other parts of the plugin that use 7.2 specific syntax will cause the php interpreter to crash. Lets say you have an init handler that uses 7.2 syntax, it will be run at init and crash the system and that will happen before the notice is displayed Mar 9, 2018 at 2:56
  • See additional answer info. That process might work to allow the plugin to require PHP7.2 without breaking sites that don't have 7.2. Mar 12, 2018 at 19:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.