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

PHP 7.2 EOL: What's Your Plan?

State of PHP
Migration

PHP 7.2 reached end of life (EOL) on November 30, 2022. As we are now several years past the end of community support, 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.

Back to top

When Is PHP 7.2 EOL?

PHP 7.2 EOL occurred on November 30, 2022.

PHP 7.2 was originally released November 30, 2017, and stopped receiving active support on November 30, 2019. As PHP 7.2 end of life has occurred, the PHP core contributors are no longer issuing updates for PHP 7.2.

Back to top

PHP 7.2 EOL: Impact on Enterprise Applications

According to the 2024 PHP Landscape Report, 18.36% of participants were using PHP 7.0 - 7.2 versions, which are no longer supported by the community. What does this mean? 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.

Back to top

PHP 7.2 EOL: Action Plans

Applications still deploying PHP 7.2 should upgrade your application to a newer PHP version or use a commercial runtime that provides an extended LTS period at their earliest convenience. Below are in-depth explorations of your options.

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.

Back to top

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 professional services and 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  Explore Professional Services

Additional Resources

Back to top