WordPress offers an API that can list the PHP versions used in the wild. It shows some interesting numbers that warrant some extra thoughts.
Here’s the current statistics in PHP versions used in WordPress installations. It uses jq for JSON formatting at the CLI.
PHP versions in 2015
$ curl http://api.wordpress.org/stats/php/1.0/ | jq '.'
{
"5.2": 13.603,
"5.3": 32.849,
"5.4": 40.1,
"5.5": 9.909,
"5.6": 3.538
}
PHP versions in 2016
$ curl http://api.wordpress.org/stats/php/1.0/ | jq '.'
{
"5.2": 7.511,
"5.3": 20.296,
"5.4": 30.264,
"5.5": 19.316,
"5.6": 20.599,
"7.0": 2.014,
"7.1": 0.002
}
3 versions stand out: PHP 5.3 is still used in 20.2% of all installations, PHP 5.4 on 30% and PHP 5.5 is at 19%.
All of these versions are end of life.
But if they’re all considered end of life, why do they still account for 76% of all WordPress installations?
Prologue: Shared Hosting
These stats are gathered by WordPress anonymously. Since most of the WordPress installations are on shared hosting, it’s safe to assume they are done once, never looked at again. It’s a good thing WordPress can auto-update, or the web would be doomed.
There are of course WordPress installations on custom servers, managed systems, … etc, but they will account for a small percentage of all WordPress installations. It’s important to keep in mind that the rest of these numbers will be mostly applicable to shared hosting, only.
PHP Version Support
Here’s a quick history of relevant PHP versions, meaning 5.0 and upwards. I’ll ignore the small percentage of sites still running on PHP 4.x.
| Version |
|---|
| 5.0 |
| 5.1 |
| 5.2 |
| 5.3 |
| 5.4 |
| 5.5 |
| 5.6 |
It’s no wonder we’re still seeing PHP 5.3 in the wild, the version has been supported for more than 5 years. That means a lot of users will have installed WordPress on a PHP 5.3 host and just never bothered updating, because of the install once, update never mentality.
As long as their WordPress continues to work, why would they – right? 1
If my research was correct, in 2005 there were 2 months where there wasn’t a supported version of PHP 5. At that time, support for 5.0 was dropped and 5.1 wasn’t released until a couple of months later.
Versions vs. Server Setups
PHP has been around for a really long time and it’s seen its fair share of server setups. It’s been run as mod_php in Apache, CGI, FastCGI, embedded, CLI, litespeed, FPM and many more. We’re now evolving to multiple PHP-FPM masters per server, each for its own site.
With the rise of HHVM, we’ll see even more different types of PHP deployments.
From what I can remember of my earlier days in hosting, this was the typical PHP setup on shared hosting.
| Version |
|---|
| 5.0 |
| 5.1 |
| 5.2 |
| 5.3 |
| 5.4 |
| 5.5 |
| 5.6 |
The server-side has seen a lot of movement. The current method of running PHP as FPM daemons is far superior to running it as mod_php or CGI/FastCGI. But it took the hosting world quite some time to adopt this.
Even with FPM support coming to PHP 5.3, most servers were still running as CGI/FastCGI.
That was/is a terrible way to run PHP.
It’s probably what made it take so long to adopt PHP 5.4 on shared hosting servers. It required a complete rewrite of everything that is shared hosting. No more CGI/FastCGI, but implementing proxy-setups to pass data to PHP-FPM. Since FPM support didn’t come to PHP 5.3 since a couple of minor versions in, most hosting providers only experienced FPM on 5.4. Once their FPM config was ready, adopting PHP 5.5 and 5.6 was trivial.
Only PHP 5.5’s changed opcache made for some configuration changes, but didn’t have any further server-side impact.
PHP 5.3 has been supported for a really long time. PHP 5.4 took ages to be implemented on most shared server setups, prolonging the life of PHP 5.3 even long past its expiration date..
If you’re installing PHP on a new Red Hat Enterprise Linux/CentOS 7, you get version 5.4. RHEL still backports security fixes2 from newer releases to 5.4 if needed, but it’s essentially an end of life version. It may get security fixes2, but it won’t get bug fixes.
This causes the increase in PHP 5.4 worldwide. It’s the default version on the latest RHEL/CentOS.
Moving PHP forward
In order to let these ancient versions of PHP finally rest in peace, a few things need to change drastically. The same reasons that have kept PHP 5.3 alive for so long.
- WordPress needs to bump its minimal PHP version from 5.2 to at least PHP 5.5 or 5.6
- Drupal 7 also runs on PHP 5.2, with Drupal 8 bumping the minimum version to 5.5.
- Shared Hosting providers need to drop PHP 5.2, 5.3 and 5.4 support and move users to 5.5 or 5.6.
- OS vendors and packagers need to make at least PHP 5.5 or 5.6 the default, instead of 5.4 that’s nearly end of life.
We are doing what we can to improve point 3), by encouraging shared hosting users to upgrade to later releases. Fingers crossed WordPress and OS vendors do the same.
It’s unfair to blame PHP, the company, that we’re still seeing 5.3 and 5.4 in the wild today. But because both versions have been supported for such a really long time, their install base is naturally large.
Later releases of PHP have seen shorter support cycles, which will make users think more about upgrading and schedule accordingly. Having a consistent release and deprecation schedule is vital for faster adoption rates.
1 Well, if you ignore security, speed and scalability as added benefits.
2 I’ve proclaimed “PHP’s CVE Vulnerabilities as being irrelevant, and I still stand by that.