How to force users to use PHP 7

In this post, I want to discuss my method of forcing PHP 7 in my WordPress plugins. Using PHP 7 has some great benefits if their server supports it, speed being the first of course. Now, your options aren’t limited to plugins for this how-to, you can also use this method in themes as well.

For this how-to, we’re going to leverage one of the little known predefined constants in PHP. Specifically, PHP_VERSION which gives us a full output of the current PHP version our server is running. We’ll be able to use yet another built-in PHP function called version_compare() to determine if the PHP version our server is using, is what we require.

Getting Started

To start this off, you’re going to need a basic plugin file, you can copy mine below if you’d like. Nothing super crazy, just something to tell WordPress “Hey I’m a plugin, I need to load.”

Simple Plugin Header

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

<?php

/*

* Plugin Name: Force PHP Version Test

* Plugin URI: https://www.plugish.com

* Description: A small plugin, delete me later.

* Author: JayWood

* Version: 0.0.1a

* Author URI: https://www.plugish.com

* License: GPLv2

* Text Domain: force-php-ver

*/

namespacecom\plugish\fpv

// Do Stuff

What to do with the main file?

Historically the main file was where you would drop all your actions, filters, and other basic functionality to get your code running. In this case, we’re going to stick with that, but use this file as our initialization file. Keeping out our version-specific syntax and function calls.

You’re going to need to create another file, let’s call it init.php. You can call it what you want, the name isn’t important, but it’s good to have a reason for what you’re calling it, makes it easier to distinguish later.

Showing the init.php file created with no content.

Personally, I use init a lot, since it’s short for initialize; and that’s what we’re going to do, initialize the plugin after our checks have passed.

Basic version Requirements

For many reasons, I like to keep functions as simple as possible. Doing so will make things more modular later. So we’re going to create two functions, one so we can set our PHP version requirements, and the second to check the requirements.

Basic Version Requirements

PHP

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

/**

* Gets the minimum required PHP version for this plugin.

* @return string

*/

functionget_minimum_php_version(){

return'7.0.0';

}

/**

* Compares currently installed PHP version with minimum requirements.

* @return bool

*/

functionis_valid_php_ver(){

return0<=version_compare(PHP_VERSION,get_minimum_php_version());

}

Note you could set your required PHP version with a class propery if you were doing a more object-oriented approach. You could also use a defined constant, but for this how-to, I wanted to keep it as simple as possible.

This is where we make use of PHP_VERSION and version_compare() to determine if we’re at least our required version. All wrapped up in just two simple functions, keeping it a bit modular.

Including your PHP 7 files

Once you have the two basic functions laid out, you guessed it; you now just need to use the conditional function to load up your init.php file – which is where all your core functionality will lay.

Load the init file, if the PHP version fits.

PHP

1

2

3

4

// Load up the main init file now.

if(is_valid_php_ver()){

require_once'init.php';

}

The init file is where you’ll have things like your actions, filters, etc… The goal is to keep the version-specific syntax out of the main plugin file so it’s not accidentally running on plugin activation.

What about plugin activation? Can’t we do something for the user to improve the experience? Absolutely, let’s get on to that!

Improving the user experience

In WordPress, we have this nifty thing called Admin Notices – I’m sure you’ve seen the nagging if you’ve installed any plugins lately. So, we’re going to leverage that by showing a notice to the Administrator if the PHP version we require, isn’t met.

<p><?phpprintf(esc_html__('Looks like your on PHP version %s. This plugin requires %s and has been deactivated.','force-php-ver'),PHP_VERSION,get_minimum_php_version());?></p>

</div>

<?php

deactivate_plugins(plugin_basename(__FILE__));

}

add_action('admin_notices',__NAMESPACE__.'\notice_failed_php_check');

In this function, we’re using the return early and often principal. If our PHP version is what we expect, we’re bailing before we display the notice; and therefore not activating the plugin.

Why not use the plugin_activation hook? Well the truth is, this function is quite lightweight, and returns early, not a lot of logic involved.

If our version does not match, we’re not bailing and essentially echoing out the HTML content telling the user what we want to say. In this case, letting them know the PHP version is not at least what we’re expecting.

Once we let them know that, we’re deactivating our plugin. Just a bit of cleanup – and a good practice overall really, cleaning up after yourself.

Showing the plugin deactivated message.

Conclusion

The overall principle is pretty easy to grasp I would hope. By keeping non-version specific code ( or say PHP 5.6 compatible code ) in the main plugin file, you’re ensuring you can at least let the user know they should be using a specific version, in this case, PHP 7.2.

One probably wouldn’t want to use this method inside of a plugin hosted on the WordPress repository, since the more downloads the better in most cases. I personally use this in an agency perspective where we can guarantee the environment we’re loading the scripts on. “But why, if we can guarantee the environment, should you use this?”, well, the answer is simple, clients move on at some point and may attempt to re-use plugins created on different software. It’s all about letting the user know what’s happening while ensuring we don’t white-screen the administrator panel.

Now, if you’re plugin does some front-end stuff, you will need to add additional checks and deactivate the plugin as early as possible. For that, the init hook may be a good option, but you’ll have to toy around with it to get the results you’re looking for.

I hope you found this helpful, it’s just a small snippet that’s in my brain and I hope you get some use out of it. Below is the full source for this, feel free to download and use as you wish!

2 Comments

With this code snippets, you are fatalling on PHP 5.2 because you use a namespace in main plugin file.
Also, it’s wiser not o deactivate the plugin, but just stop loading it. So this notice will notify users all the time until they manually deactivate or fix their PHP (which is super easy on lots of hosts, like SiteGround).

Valid points here, didn’t really think about 5.2 myself – I feel for anyone still using it though. As far as deactivating, yea, personal preference really, just one of the many ways to handle this 😀 thanks for the feedback!