Haven’t upgraded to PHP 7? You’re not alone.

According to W3Techs, PHP is used by 79% of websites, and according to BuiltWith, PHP is used by 39% of websites (August, 2019). Even though the estimates differ, we can clearly see PHP is a very popular website language. This popularity is consistent with most programmers’ experience.

Both websites have PHP as the most popular language for websites.

PHP was relatively recently upgraded, breaking backwards compatibility. PHP 7.0 was released at the end of 2015, and support for the previous stable version, PHP 5.6, was ended at the end of 2018. (Version 6 was skipped.) This gave companies, open source projects and developers three years to upgrade their code. Needless to say, many did not, and now they are facing an increasing list of security problems.

According to W3Techs, 37% have upgraded.

According to wordpress.org, home page of the very popular website framework, WordPress, 55% have upgraded (August, 2019).

This leaves an enormous amount of websites with an increasing security problem, technical debt and the looming demand of spending an unknown amount of time, effort and money on upgrading, taking away precious time for developing new features.

For many, the upgrade is not only costly, but also risky or almost impossible. One reason is that libraries or vendor-supplied software might not work with version 7.0 (or above). The companies are dependent on the vendors or open source projects to upgrade first: The vendors might no longer be around and the open source project might have lost its contributors.

One can easily shrug at this and say: What is the problem? Software must evolve, following the ever changing and improving world of programming. Projects and businesses must adapt or die, and those who die, deserved it. But a deeper look at coding practices shows that this view is over-simplified.

What advice were the developers of PHP given in 2015 and before, and when PHP 7.0 was not even conceived of? The advice most programmers of most languages get: Exploit the whole language, use everything in order to make the code short and elegant. The designers put the feature in for a reason, for you to write shorter, more efficient and more readable code. Language designers are very smart: They carefully architected the language for us to have efficient and productive days of coding. Fewer lines of code means fewer bugs, and these new, cool features allow us to reduce the number of lines of code by 20%.

This is all well and good until the language designers change their minds, enter the infamous breaking changes. All the cool kids agree, what was hot is now not (refering to Kotlins increasing popularity over Java). What about all the old code? That’s legacy, and no one wants to work on that anyway. The world has moved on. The stock holders, never knowing the risk, are left with the bill.

We have all heard the above advice, and, as it stands, it inevitably leads to the current situation with PHP. Is there an alternative? Yes. When writing a software module, carefully think about which features of the programming language you need. Is this a short term module or a long term module? If it is long term, will these language constructs continue to function? This and other questions can protect the software from being costly to upgrade.

For more articles on programming for the long run, check out other articles in the progsbase blog.

Leave a Reply

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