Mark Jaquith: Handling old WordPress and PHP versions in your plugin
New versions of WordPress are released about three times a year, and WordPress itself supports PHP versions all the way back to 5.2.4.
What does this mean for you as a plugin developer?
Honestly, many plugin developers spend too much time supporting old versions of WordPress and really old versions of PHP.
It doesn’t have to be this way. You don’t need to support every version of WordPress, and you don’t have to support every version of PHP. Feel free to do this for seemingly selfish reasons. Supporting old versions is hard. You have to “unlearn” new WordPress and PHP features and use their older equivalents, or even have code branches that do version/feature checks. It increases your development and testing time. It increases your support burden.
Economics might force your hand here… a bit. You can’t very well, even in 2018, require that everyone be running PHP 7.1 and the latest version of WordPress. But consider the following:
97% of WordPress installs are running PHP 5.3 or higher. This gives you namespaces, late static binding, closures, Nowdoc, __DIR__, and more.
88% of WordPress installs are running PHP 5.4 or higher. This gives you short array syntax, traits, function-array dereferencing, guaranteed <?= echo syntax availability, $this access in closures, and more.
You get even more things with PHP 5.5 and 5.6 (64% of installs are running 5.6 or higher), but a lot of the syntactic goodness came in 5.3 and 5.4, with very few people running versions less thatn 5.4. So stop typing array(), stop writing named function handlers for simple array_map() uses, and start using namespaces to organize and simplify your code.
Okay, so… how?
I recommend that your main plugin file just be a simple bootstrapper, where you define your autoloader, do a few checks, and then call a method that initializes your plugin code. I also recommend that this main plugin file be PHP 5.2 compatible. This should be easy to do (just be careful not to use __DIR__).
In this file, you should check the minimum PHP and WordPress versions that you are going to support. And if the minimums are not reached, have the plugin:
- Not initialize (you don’t want syntax errors).
- Display an admin notice saying which minimum version was not met.
- Deactivate itself (optional).
Do not die() or wp_die(). That’s “rude”, and a bad user experience. Your goal here is for them to update WordPress or ask their host to move them off an ancient version of PHP, so be kind.
Here is what I use:
Reach out on Twitter and let me know what methods you use to manage PHP and WordPress versions in your plugin!
Do you need WordPress services?
Mark runs Covered Web Services which specializes in custom WordPress solutions with focuses on security, speed optimization, plugin development and customization, and complex migrations.
Please reach out to start a conversation![contact-form]