decorative image for blog on php 7.2 eol
November 19, 2020

Preparing for PHP 7.2 EOL

State of PHP
Migration

With PHP 7.2 end of life (EOL) rapidly approaching, it's important for teams to consider their long-term support and migration options.

In this blog, we discuss the impact of PHP 7.2 EOL, and the steps teams need to take to upgrade or support their application.

When Is PHP 7.2 EOL?

PHP 7.2 was originally released November 30, 2017, and stopped receiving active support last year, on November 30, 2019. At the time of writing, we’re in the last two weeks of the release’s security window, which ends on November 30, 2020, after which time the PHP core contributors will no longer issue updates for the version.

Potential Impact on Enterprise Applications

What does this mean for users of PHP 7.2? It means that if any vulnerabilities are reported against it, they will no longer receive security patches, leaving applications that are running on it exposed and vulnerable.

For users of operating systems (OS) with long term support (LTS) offerings, your PHP binary often continues to receive patches by the OS vendor even once the community support window has ended. In the case of Ubuntu 18.04 and RHEL / CentOS 8, which each ship with PHP 7.2, this means you may continue to get patches going forwards. If the operating system you are on is not under an LTS policy, however, then your version will become vulnerable to new exploits as time progresses.

How to Prepare for PHP 7.2 End of Life

When it comes to preparing for the PHP 7.2 EOL, you have two options: upgrade your application to a newer PHP version, or use a commercial runtime that provides an extended LTS period.

1.Upgrading to a Newer PHP Version

The gold standard for helping you migrate to a new PHP version is the PHPCompatibility project. PHPCompatibility is a ruleset for PHP_CodeSniffer, providing both detection of compatibilty issues and the ability to fix many of them. To use it, you will install both PHP_CodeSniffer and PHPCompatibility in your project using Composer, and then run “./vendor/bin/phpcs -p {path to your code} --standard=PHPCompatibility --runtime-set testVersion {target PHP version here}”. The command will send a report to the console with detailed information on compatibility issues, often with information on how to fix them.

Another tool you can use is Rector. Rector provides rules and rulesets for auto-migrating/auto-rewriting code, and these include rulesets for each PHP minor version. As examples of things it can do, it might rewrite the name of a now-deprecated function to its replacement (e.g., when migrating to PHP 7.4, rewriting “is_real()” to “is_float”, or “apache_request_headers()” to “getallheaders()”), or update the code to use new features in place of legacy functionality (e.g., instead of using the “__CLASS__” magic constant, using “self::class”). The tool can take what would normally be hours or days of work, and turn it into minutes.

One last tool you have is to hire an outside consultant or company to assist you with your migration. At Zend by Perforce, for example, we provide Professional Services engagements to help you upgrade your code base to work on newer PHP versions.

One thing to watch out for: any time you do a migration, you should ensure you have adequate testing in place prior to starting, to ensure any changes you make do not break existing functionality. If you don’t have good testing in place, that’s the first step you should take before performing a version upgrade! Zend by Perforce can help you with testing, too.

2. LTS Runtimes

If a version upgrade seems to costly in terms of time or ability to continue delivering new features and fixes for your web application, another option is to look into LTS runtimes.

As mentioned previously, your operating system may already provide these. However, you should investigate if there is a way to auto-update your binaries, and/or get notifications when new versions are ready to install. You should also examine what the OS policy is with regards to security issues: how quickly do they patch, what severity of vulnerabilities do they patch, etc.

What if you want to use a PHP version different than what your OS ships? Or what if your OS is not able to provide support any longer? Another alternative you have is to identify commercial vendors of LTS runtimes. These may be Platform-as-a-Service providers, where the runtime is guaranteed in applications you deploy with them.

Another option is, of course Zend by Perforce, where we offer LTS for each version of PHP for a minimum of 2 years after community support ends for the version. This is particularly interesting if you want to stick with a PHP version longer than your OS supports it, or if you want to use a PHP version unsupported by your OS.

Final Thoughts

The PHP roadmap is public, and at any given time, three versions of PHP are currently supported. This also means that every single year, a version of PHP reaches its end of life, just as PHP 7.2 is reaching its end this year. Your company and products should either account for this cadence and have product roadmapping in place to regularly upgrade, or budget for LTS runtimes so you can prolong the lifespan of applications that are costly to upgrade.

In both cases, Zend by Perforce has your back!

Get Support for Your EOL PHP With Zend

Zend offers secure, supported PHP runtimes for EOL PHP versions. They feature around the clock support, backported patches, and bug fixes. See how we can support your EOL PHP version by clicking the link.

See LTS Runtimes

Additional Resources

Want to see what's coming in PHP 8? In this webinar, I look at the big changes to expect in PHP 8, and what features like the new JIT compiler can mean for performance.

Looking for additional resources on upgrading or supporting EOL PHP versions? These resources are a great place to start. I highly recommend the white paper on the hidden costs of PHP upgrades, especially if you're working on an large-scale application.