Innovate faster and cut risk with PHP experts from Zend Services.
Beginning to advanced PHP classes to learn and earn global certification.
Help me choose >
Submit support requests and browse self-service resources.
Why upgrade to the latest PHP version? Well, we have 4 good reasons!
PHP — unlike RPG, with its backward compatibility of over 60 years — supports a backward compatibility range of about 3 years or so. Some developers who keep their ears to the ground are aware of bad practices of potentially deprecated features typically listed on the php.net site. And while this may seem terribly disruptive, the number of true backward compatibility issues is usually rather small.
In this blog, we’ll break down the four main reasons to upgrade your PHP stack on IBM i — in no particular order, as each of these reasons is hugely important.
Please keep in mind that sometimes shops simply do not have cycles to invest in upgrading their PHP stack. For that reason, Zend offers long term support (LTS) for older PHP versions which can extend the community support by a few years. We’ll talk more about that in a bit and, where applicable, I tried to provide a link to the original source materials so you don’t have to take my word for it.
One of the primary reasons the PHP community removes features from PHP is because it is a “perimeter” technology and the times do tend to change. RPG is typically implemented as a back office technology, so it is often tucked safely behind a firewall letting some other server or language serve up the web like PHP.
Since PHP is closer to the web, we sometimes refer to that as a “perimeter” technology. As a result, the PHP community remains vigilant about elements of the language that could be misused or abused by both hackers and the developers using the language. Since these changes are implemented via subsequent versions and releases, keeping up with your PHP version is important. The Help Systems Survey identifies security as the number one concern among the survey respondents with about ¾ of all respondents indicating this is important, a sentiment echoed in our own PHP Landscape Report as one of the top development priorities.
I have also heard the response from some of the IBM i community that “My PHP is only on the intranet, so I don’t have to worry about security.” As many IBM i security professionals will tell you, that is a myth — up to 80% of hacks originate from within the organization. Also, all it takes is a simple firewall mistake to make your site public facing.
The implementation of Libsodium as a core extension and the slow, grueling elimination of global variables signal the perpetual march toward a safer PHP experience. But as many would tell you, security is an ongoing journey and not a destination.
In recent versions of PHP, there have been many performance improvements in nearly every release. Let’s focus on a handful of them, with the most notable being PHP 7.
While PHP 7 has been out for a while, 25% of servers (as of the time of this writing) are still on PHP 5 according to w3techs. Just by upgrading to PHP 7, many shops would see a performance boost in pure PHP processing, as many aspects of the language were re-written with an eye on optimizing the PHP code itself and more efficient memory utilization.
Now, the reality is that your database i/o is probably more expensive than the PHP processing, but all these elements add up. PHP 8 builds on that incredible advancement with additional features like a couple of Just-In-Time compilation engines.
Other aspects of speed beside just pure PHP performance include the far more important “programmer productivity.” One of the opportunities presented when upgrading PHP is the opportunity to consider restructuring code. Regarding refactoring, Uncle Bob says “You always do it . . . like washing your hands when leaving the bathroom.” But what about the monolith or a honking huge code segment that should be broken down? Restructuring old code into more modern modular code can increase the performance of the developers maintaining and supporting those systems. Sometimes a nice backward compatibility break can usher in the opportunity to strike at those hideous monstrosities.
One of the more popular anecdotes I have read about — 20% of the performance of PHP 8 was derived by the elimination of the underlying code supporting PHP 4 constructors.
ZendPHP and Zend Server customers enjoy something awesome called LTS. By implementing new versions of PHP with Zend Support, you get more time between version updates as Zend backports security fixes to versions of PHP that have been abandoned by the community support.
Not every company has the time to address PHP maintenance each year. Things happen, budgets get crushed, surprise projects or acquisitions happen. Then, it’s “all hands on deck” for the emergencies, and the server maintenance gets shoved on a back burner.
For those who don’t have the time: budget some time for this in each cycle, and get on LTS. Having LTS for your PHP stack is like having “Project Insurance.”
While it’s not a great idea to put off these updates, wouldn’t it be nice to have that luxury, just in case? This support option is leveraged by thousands of companies worldwide to extend the life of a given PHP version beyond the community support window. You can read more about the LTS options on the Zend website where we have a handy chart that clearly outlines the support timelines by version. By adding up to 3 more years to a PHP version, some companies can hold off on a major version change until they are staffed up or they get a break in the backlog. However, you shouldn’t wait forever — even the Zend LTS ends at some point.
The PHP community is never at a loss for adding new features to PHP. These kinds of things can add productivity to your site, as well as to development teams. There have been many new features added to PHP over the last few releases. One, in particular, highlights the example of not only a new feature, but also productivity.
Constructor property promotion is new in PHP 8.0 and offers developers an opportunity to move quicker when defining the constructor properties of an object. If you look at the original RFC that proposed the feature, it becomes clear why this might be attractive. Think of some of the larger objects out there being hydrated with a bunch of constructor properties. A lot less code and a more meaningful class definition. I highly recommend reading the RFC proposals as that give the developer some insight into the reason for the recommendations.
Before PHP 8.0:
After PHP 8.0:
I would posit that probably the most important aspect of upgrading PHP is the access to new features, but your mileage may vary.
PHP 7.0 offered tremendous performance improvements over PHP 5. PHP 8.0 touts a “just in time” processor, and both versions offered up hundreds of new functions, methods, and behaviors. PHP 8.1 introduces Fibers to the languages for the Node.js enthusiasts out there. PHP 8.2 is warming up and the RFCs are being evaluated. PHP 9 will probably do something incredible, but it is a little too soon to tell as that version is probably several years off.
Looking for LTS or migration help? Contact us today to get started!
With free PHP 7.4, 8.0, and 8.1 runtimes from Zend, your team can evaluate Zend PHP runtimes without a commitment.
Start Free Trial
Sr. Solutions Engineer, Zend by Perforce
Mike has been working with IBM midrange solutions since 1992 and IBM Mainframes before that. Mike was instrumental in developing the adoption of PHP as a primary solution for web development on IBM i working with Zend Technologies. Today, as Senior Sales Engineer with Perforce, Mike helps companies around the world approach the challenges of modernization and open source technologies. In addition to several roles as a volunteer with COMMON the premier IBM midrange user group, Mike also teaches PHP & Python classes part time at Moraine Valley Community College in Suburban Chicago.