Why We’re Still Seeing PHP 5.3 In The Wild (Or: PHP Versions, A History)

Mattias Geniar, Wednesday, July 29, 2015 - last modified: Friday, July 29, 2016

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 Released End Total duration
5.0 July 13th, 2004 September 5th, 2005 419 days
5.1 November 24th, 2005 August 24th, 2006 273 days
5.2 November 2nd, 2006 January 6th, 2011 1526 days
5.3 June 30th, 2009 August 14th, 2014 1871 days
5.4 March 1st, 2012 September 14th, 2015 1292 days
5.5 June 20th, 2013 July 10th, 2016 1116 days
5.6 August 28th, 2014 August 28th, 2017 1096 days

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 Server setup
5.0 Apache + mod_php
5.1 Apache + mod_php
5.2 Apache + suexec + CGI
5.3 Apache + suexec + FastCGI
5.4 Apache + FPM
5.5 Apache + FPM
5.6 Apache + FPM

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 fixes[2] from newer releases to 5.4 if needed, but it's essentially an end of life version. It may get security fixes[2], 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.

  1. WordPress needs to bump its minimal PHP version from 5.2 to at least PHP 5.5 or 5.6
  2. Drupal 7 also runs on PHP 5.2, with Drupal 8 bumping the minimum version to 5.5.
  3. Shared Hosting providers need to drop PHP 5.2, 5.3 and 5.4 support and move users to 5.5 or 5.6.
  4. 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.

Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek & public speaker. Currently working on DNS Spy & Oh Dear!. Follow me on Twitter as @mattiasgeniar.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!


Matthias Thursday, July 30, 2015 at 11:47 - Reply

There are lots of reasons why administrators do not bother to upgrade either the CMS or PHP. But most of them can be brought down to: investment of time and – thus – money.

Investing in continuous upgrades is a very hard sale:

As a consultant, I’ve dealt with my fair share of legacy systems. Dependencies are the first problem. Which stuff will break on upgrade and how long would it take to fix them? There is no conceivable way of estimating the workload up front realistically. It’s a major reason why in Drupal even upgrading modules is often avoided: too much potential hassle.

An upgrade to the next major version is most often tied to a “build the site again from scratch and migrate the content” project. Those cycle maybe once every 3 to 5 years and you are lucky if you are still dealing with the same people who were there when the project kicked off.

Then, what is the business value for a client to invest in upgrades? Why would I spent $$ on taking the stack apart? It’s not like I’m going to get new features or more visitors to my site. Performance? Maybe, but for the vast majority of websites, that probably wouldn’t return a real gain. Security? Definitely! But security is like insurance: if the continuous effort of upgrading is too expensive (short cycles), taking a risk and skipping an upgrade becomes an attractive option.

Don’t get me wrong: I agree that we should keep pushing for regular upgrades of software. But we can’t expect that decision makers will follow suit just because of a best practice. What I’m saying is: we should at least acknowledge that this is not solely a technological problem.

    Peter Thursday, July 30, 2015 at 18:03 - Reply

    I came here to say the same thing.

    Think as if you’re a typical WordPress website owner on shared hosting:

    You buy a website because your business needs it
    You don’t understand that it needs updates (especially when updates can break things, which the unreasonable developer wants to charge money to fix, even though they broke it) — until you’ve been hacked once or twice

    If the hosting company updates the PHP version and it breaks your site, that’s not your fault, and you are going to get the hosting company to fix it at their expense. Or be very pissed off with the hosting company, badmouth them and move elsewhere.

    I see this mindset with bigger businesses. Heck, I worked on a security-conscious embassy website, which still chose £4.99/month shared hosting…

    And the hosting company is in a difficult position, as ‘man in the middle’. They want to update their infrastructure but can’t if their customers won’t upgrade.

    I see only one solution: education and changing mindset. Unfortunately, that’s been the solution since I started 15 years ago, and I haven’t succeeded or seen others succeed. Because the typical website owner doesn’t understand, doesn’t want to, and shouldn’t need to.

    I don’t know the solution, but it’s a great discussion to be having :-)

Tomas Thursday, July 30, 2015 at 18:51 - Reply

Ubuntu with LTS updates PHP 5.3.10 with security fixes, you can check it here.


Aji Sunday, October 18, 2015 at 12:22 - Reply

I just read your website, and I’m kinda agree with you.
Most web hosting companies should upgrade their hardware for further improve their security in PHP.
I’m from Indonesia, and here there’s one big web hosting company that still use PHP 5.3, when I asked can I upgrade it to newer PHP (it was 2011 back then) they said they can’t because most of their shared user still run script for PHP 5.2 or 5.3.
Of course one of the many issue why I MUST use latest PHP is for security purpose for my CMS website like Joomla and WordPress. So far I managed to use Hostgator and SiteGround, but they are so expensive.

Grzchr15 Saturday, February 13, 2016 at 20:43 - Reply

As long as even redhat does not make it easy to get php > 5.4 no one will update scripts. We are still forced to stay at those old versions.

    Mattias Geniar Sunday, February 14, 2016 at 16:34 - Reply

    Very true, indeed.

    In fact, Red Hat’s policy of backporting security issues to PHP 5.4 is hurting the adoption of more recent PHP versions, too. Why bother upgrading if your OS supplier helps patch those ancient, unsupported versions anyway? (1)

    (1) besides the speed, memory & new functions/language options, of course.

Smokezz Friday, February 19, 2016 at 23:09 - Reply

RedHat’s policy of backporting security updates is how all enterprise OS’s work. Ubuntu doesn’t upgrade versions of PHP within a release of their server OS either. Companies rely on an operating system not updating things suddenly and breaking all of their applications running on their server.

It would be nice however if RH would release RPM’s for more than just PHP 5.3 on CentOS 6, 5.4 on CentOS 7. Relying on a 3rd party repo isn’t that great of an option as those 3rd party repos do NOT backport security updates. Not a whole lot different than compiling from source.

Sean Prunka Friday, July 29, 2016 at 16:00 - Reply

If Phil Sturgeon’s pet project http://phpversions.info/ gains enough traction (and help from the developer community to keep it maintained) maybe more hosting providers will begin to get the message that we do not just want the upgrades, we need them.

pcarvalho Wednesday, June 21, 2017 at 17:03 - Reply

fast skipping to Jun/2017: nothing changed :/

Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links