The official stance of WordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ is that WordPress is supported on PHP 5.2.4 or greater.
The official stance of the Plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Team regarding what version of PHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.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>';" ) );
return;
}
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>';" ) );
return;
} 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>';" ) );
return;
}
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__ ) );
}
return;
} 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.
#php