WordPress To Move to PHP 5.6+

WordPress 5.2 is due out at the end of April, and wit that release the minimum recommended version of PHP will be PHP 5.6.

Minimum PHP Version update

For most plugins this is a non-issue. While we recommend you update your “Requires PHP:” version in your readme.txt, this won’t change the functionality of your code. That field is a minimum version, so if your code works with 7.0 and up, you can set it to `Requires PHP: 7.0` and that will cover 7.1 and 7.2

Also keep in mind, this doesn’t change our policy on PHP versioning, which is to say we still do not have an official version requirement for PHP in your plugins. If you want to support 5.6 forever, feel free. If you want to require 7.1 and up, again, go for it.

You can use a compare to do the basic check:

version_compare( PHP_VERSION, '5.6', '<' )

And remember the goal for your plugin is “Don’t break things for users.” Stop them from getting fatal errors, and don’t run your plugin if you know it can’t work.


‘Policy’ on PHP Versions

The official stance of WordPress.org is that WordPress is supported on PHP 5.2.4 or greater.

The official stance of the Plugin Team regarding what version of PHP your plugins can use is .. not that.

We don’t have an official stance. We’ve never needed one. We do (often) test complex plugins on multiple versions of PHP (and sometimes HHVM) to make sure there’s proper degradation and support, but at the same time, we do not have an official requirement that you must support version X or Y.

This is not an official requirement post.

This is a reminder post.

Use whatever version of PHP works best with the code you’re writing. If you’re using, for example, Amazon S3’s library, you must use PHP 5.3 and up because otherwise the libraries won’t work. From that standpoint, your plugin should require PHP 5.3 and up. That’s a decision prompted by circumstances outside of WordPress.

For everyone who just wants to know what to do if your plugin must be on PHP 5.3 or 5.4, the answer is this:

Make sure your plugin checks for any and all requirements on activation and, if they’re not found, it should gracefully fail and alert the user as to why.

This includes things like required software (if your plugin is an add-on to WooCommerce, yes, check that WooCommerce is installed and active), but also PHP versions and (if needed) SQL versions. That’s your responsibility. We’re not going to force you to do it at this time, but understand that your plugin’s reviews and ratings will be directly impacted by how you handle those things.

Fail gracefully. Degrade gently. Error politely. Consider your users. Remember: WordPress can be used on anything.

This can be complicated or not, depending on your requirements. The main thing to think of here is that if you don’t support PHP 5.2, then your main plugin still needs to work in PHP 5.2.

Practical Examples

Let’s say you use a function that only works in PHP 5.3 and up. A simple function_exists check will do the job:

if ( !function_exists( 'some_function' ) ) {
    add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.3 to function properly. Please upgrade PHP or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );

Note the use of create_function here, because anonymous functions (aka closures) don’t work in PHP 5.2.

The use of return prevents the rest of the plugin from executing here, preventing that function call later from causing a syntax error.

Sometimes though, you need more complicated checks. Let’s say your plugin uses PHP namespaces. Those are not supported in PHP 5.2, and will cause a syntax error just from having them in the file, before any of your code runs.

So, your main plugin file needs to not have namespaces and basically only be a shiv to load the rest of the plugin from another file if the requirements are met:

if ( version_compare( PHP_VERSION, '5.3', '<' ) ) {
    add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.3 to function properly. Please upgrade PHP or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );
} else {
    include 'rest-of-plugin.php';

Here, the plugin does not load the files that can cause errors unless the requirements are met.

Maybe you need to check against the WordPress version. Plugins load in the global context, so the $wp_version variable is available to you to check:

if ( version_compare( $wp_version, '4.0', '<' ) ) {
    add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires WordPress 4.0 to function properly. Please upgrade WordPress or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );

Although, if you’re requiring a specific WordPress version, then you’re more likely to be requiring a specific function instead, in which you should check for that specific function as in the first example.

If you want to be complicated about it, you can indeed do so. Here’s code for a plugin which will deactivate itself if the PHP version requirement is not met:

if ( version_compare( PHP_VERSION, '5.4', '<' ) ) {
    add_action( 'admin_notices', create_function( '', "
        echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.4 to function properly. Please upgrade PHP. The Plugin has been auto-deactivated.', 'plugin-name') ."</p></div>'; 
        if ( isset( $_GET['activate'] ) ) 
            unset( $_GET['activate'] );
        " ) );
    add_action( 'admin_init', 'pluginname_deactivate_self' );
    function pluginname_deactivate_self() {
        deactivate_plugins( plugin_basename( __FILE__ ) );
} else {
    include 'rest-of-plugin.php';

The reason for the unset of $_GET[‘activate’] here is so that the normal plugin activation process will not show the normal activation message, showing the plugin’s message only.

These are not the only ways to perform a check like this, however they should be enough to get you started. Remember: Make things obvious to your users what the problem is, so they can understand the situation and take action.


MySQL in WordPress 3.9 – Implications for Plugin Authors

If you’re a plugin developer and you have a plugin using any of the php mysql functions directly, then you might start to see breakage in WordPress 3.9.

See, the php mysql extension is very old. As of PHP 5.5, it’s also deprecated and will very likely not be receiving further updates.

So starting in WordPress 3.9, if PHP 5.5 is being used, the built in WPDB class will switch to using the mysqli extension instead.

What this means for your plugin is that if you’re using any mysql_* functions directly, and somebody tries to use your plugin on a WordPress 3.9 + PHP 5.5 system, then all your database code will no longer work properly. Since the mysql functions are no longer being used in such a case by WordPress, then there is no longer an implicit database connection available to these function calls.

Instead of using a direct database connection, you can switch to using the global $wpdb instance of the WPDB class to access the database. @pento gives a great rundown on what functions to use as drop-in replacements on this make/core post: https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/

Now, as this is currently limited to PHP 5.5 and up only, the amount of breakage will likely be very minor. Our stats currently show that PHP 5.5 is being used on less than 1% of installations. Nevertheless, hosts are starting to upgrade PHP versions more and more frequently. This number is thus expected to grow over the next year or two. So before your users start having broken sites, please, take the time to switch your plugins over to the WPDB based methods. This will ensure future compatibility and minimal breakage.

WordPress will always maintain backward compatibility in its own functions, so using them ensures that you’ll be good for the forseeable future, no matter what database methods are being used internally.