I recently saw this tweet from Danny van Kooten which reminded me of one of the many major gripes developers have with WordPress – supporting ancient PHP versions:
STOP SUPPORTING PHP 5.2 IN YOUR NEW PROJECTS.
No one using it is actively installing plugins, trust me.
— Danny van Kooten (@dvkoot) February 27, 2018
Yes, (unbelievably) WordPress still supports installations of PHP 5.2.4! As plugin developers, we can’t change that over night but we have the power to stop supporting these legacy versions in our plugins where we have control over the codebase.
WordPress has always had a noble commitment to backwards compatibility which, although it seems to be wavering with Gutenberg, has meant no site has broken due to being on an ancient shared hosting server with a host who doesn’t upgrade PHP.
WordPress.org does recommend PHP 7.2 for installations but that’s a soft requirement encouraged only on the website copy, and means that WordPress can still work on four branches of PHP at end of life, that are no longer supported, and two branches that are only receiving security fixes until the end of 2018:
|5.5||1 year, 7 months ago|
|5.4||2 years, 5 months ago|
|5.3||3 years, 6 months ago|
|5.2||7 years, 1 month ago|
If we dive into the numbers we can see that the number of WordPress installs on these four PHP versions make up 35.7% of all self-hosted WordPress installs:
The numbers for WordPress core are going to be different to statistics for installs of specific plugins. Free plugins on the WordPress plugin repository are allowed to collect usage data with consent. Danny van Kooten is the author of the popular MailChimp for WordPress plugin and has been collecting data for some time and has shared his findings:
Some actual data to back this-up. Do you really want to spend time and abandon the use of new & useful PHP features/libraries because of that 0.64%? pic.twitter.com/MZZVqnDkCE
— Danny van Kooten (@dvkoot) February 27, 2018
We collect PHP version data for our own premium plugins to help inform our decisions about future features and code compatibility, and have seen a similar trend in versions:
Security is a big reason to upgrade. PHP security vulnerabilities are discovered all the time but are no longer patched in PHP 5.2 to 5.5. Just as the WordPress community advocates constantly updating WordPress core and plugins, the same should be applied to PHP versions.
Site speed and performance should be a key concern for site owners and developers. I’ve said it before and I’ll say it again: a fast site == happier users, improved ranking from Google, and increased conversions. It turns out keeping up with the latest PHP version could see large performance improvements.
The folks over at Kinsta have produced a yearly PHP benchmark post that just highlights how significantly faster PHP becomes with each version:
PHP 7 allows the system to execute twice as many requests per second in comparison with the PHP 5.6, at almost half of the latency.
Developing plugins when WordPress supports a wide range of PHP versions is extremely problematic. There is a vast difference between the type of PHP you can write between these versions, which affects how you write code and can have an effect on the user experience of your plugin. Constantly testing all aspects of your plugin on a wide range of PHP versions is exhausting and will ultimately lead to broken experiences and the odd white screen of death.
Different PHP versions introduce new features of the language that make life easier as a developer. But if we have to support extreme legacy PHP versions we can’t easily use these features without version-checking and hacks for older installs. Let’s take a look at some of the PHP goodness we could all be using if WordPress bumped the minimum PHP version:
|5.3||Namespaces, closures, late static bindings|
|5.4||Traits, short array syntax, class member access on instantiation has been added|
|5.5||Class name resolution via ::class|
|7||Anonymous classes, scalar type declarations, return type declarations, constant arrays using define()|
|7.1||Nullable types, class constant visibility|
|7.2||New object type, abstract method overriding|
What Can You Do?
So what can you do to reduce the number of installs on legacy PHP versions and allow you to code happy?
For plugins on the WordPress repository, a quick and easy approach to alert new users to the minimum PHP version your plugin supports is using a directive in the readme.txt file. The
Requires PHP header was introduced back in August 2017 and displays this on the plugin page on the repository:
However, this isn’t a hard restriction and users can still install the plugin, but it’s a first step to get plugins to adopt the standard that WordPress can then use to impose further restrictions during the installation process, an approach that is still being discussed on Trac.
The team at Yoast are doing great work to encourage their legacy PHP user base to upgrade with a non-dismissible notice for installs that aren’t on PHP 5.6 or above. They even have started a community effort to whip hosts into shape and have a neat open source package plugin developers can use to add a notice to encourage your users to upgrade.
While we wait for the Trac discussion to roll on and the WordPress development wheels to turn we can take action ourselves in our plugins to stop them working on installs that don’t meet our requirements. We do this in our own plugins where it is strictly necessary (WP Offload S3 relies on the Amazon Web Services S3 SDK, which requires PHP 5.3.3+ and will we will move to PHP 5.5 in the future), and the more plugins that do this out of choice will help move the needle further.
The servehappy project is an initiative that seeks to educate WordPress site owners about the value of having the latest version of PHP powering their WordPress site. This supports the overall goal of increasing the percentage of WordPress installs running modern PHP versions.
I hope 2018 is the year WordPress drops PHP 5.2 support but I won’t hold my breath. We need to push this forward in any way we can, so let’s stop supporting (really) legacy PHP versions in our plugins and if you build sites for clients make sure you get them hosted somewhere that cares about PHP versions.
Are you encouraging your users to upgrade or do you refuse to support legacy PHP versions in your plugins? Let us know in the comments.