PHP is evolving steadily. Every year, there is a major new release containing new features, performance improvements, a fair share of deprecations, and even syntax changes. PHP core developers maintain the two latest PHP versions with active bug fixes and security fixes, followed by security fixes. This effectively means that each major PHP version will be supported at most for three years, and existing PHP applications are forced to upgrade.

PHP 正在稳步发展。每年，都会有一个重要的新版本，其中包含新功能、性能改进、相当多的弃用，甚至语法更改。PHP 核心开发人员维护两个最新的 PHP 版本，其中包含活动错误修复和安全修复，然后是安全修复。这实际上意味着每个主要的PHP版本最多将支持三年，并且现有的PHP应用程序被迫升级。

While updating existing PHP applications is the ideal and recommended approach, inevitably, there are some applications/websites that cannot justify the human, political, and financial cost of the update. This is especially the case for legacy PHP applications that run on PHP 5 series or PHP 7 series. WordPress.org, for example, reports that only 16% of the reported WordPress sites run on a PHP version supported by the PHP core developers.

虽然更新现有的PHP应用程序是理想和推荐的方法，但不可避免地，有些应用程序/网站无法证明更新的人力，政治和财务成本是合理的。对于在 PHP 5 系列或 PHP 7 系列上运行的传统 PHP 应用程序尤其如此。例如，WordPress.org 报告说，只有16%的WordPress网站运行在PHP核心开发人员支持的PHP版本上。

PHP Version distribution, reported by WordPress.org PHP 版本分布，由 WordPress.org 报告

Updating a PHP application to be compatible with the latest PHP version is on a wide spectrum of difficulties. This can range from requiring no or little changes to what feels like a complete rewrite. PHP applications that were developed over a decade ago pose the biggest challenge because they tend to use PHP extensions that are no longer supported, have no type support, and often have no automated tests to verify the changes either.

更新 PHP 应用程序以与最新的 PHP 版本兼容存在很多困难。这可能包括不需要或很少更改到感觉像完全重写的内容。十多年前开发的PHP应用程序带来了最大的挑战，因为它们倾向于使用不再支持的PHP扩展，没有类型支持，并且通常也没有自动测试来验证更改。

Tools such as Rector can automate some, if not most, of the changes necessary, but extremely old PHP versions tend to require a lot of manual code updates.

像Rector这样的工具可以自动执行一些（如果不是大多数）必要的更改，但是非常旧的PHP版本往往需要大量的手动代码更新。

In some cases, the cost of upgrading is not worth the effort and the cost. Some of the examples include internal applications that are only used within a private network, applications that are planned for a rewrite, and applications that the original developers are no longer working at the company. Realistically, these applications may never get updated; only eventually replaced.

在某些情况下，升级的成本不值得付出努力和成本。其中一些示例包括仅在专用网络中使用的内部应用程序、计划重写的应用程序以及原始开发人员不再在公司工作的应用程序。实际上，这些应用程序可能永远不会更新;只有最终被替换。

Because PHP versions receive official updates for only up to three years, this can leave the applications vulnerable to security vulnerabilities that often affect these unmaintained PHP versions as well. PHP Platform-as-a-Product (PAAS) offerings and shared hosting providers also force updating to a recent PHP version which can leave the applications broken on the new PHP version as well.

由于 PHP 版本最多只能接收三年的官方更新，因此这可能会使应用程序容易受到安全漏洞的影响，这些漏洞通常也会影响这些未维护的 PHP 版本。PHP平台即产品（PAAS）产品和共享托管服务提供商也会强制更新到最新的PHP版本，这也可能导致应用程序在新PHP版本上损坏。

This article discusses strategies for running legacy PHP applications on a secure PHP environment, with additional security precautions and maintenance, thus extending the lifetime of said PHP applications. 本文讨论在安全的 PHP 环境中运行旧版 PHP 应用程序的策略，以及额外的安全预防措施和维护，从而延长所述 PHP 应用程序的生命周期。

The more a PHP application stays locked into a PHP version, the steeper it gets to update. However, squeezing a few more years out of a legacy application until it is replaced is sometimes more realistically viable compared to updating a decades-old PHP application.

PHP 应用程序被锁定在 PHP 版本中的次数越多，更新的难度就越大。然而，与更新几十年前的PHP应用程序相比，从遗留应用程序中再挤出几年直到它被替换有时更现实可行。

共享主机和平台到专用服务器

Most shared and managed hosting platforms and PHP PaaS offerings usually only offer the current PHP versions, but do not support old PHP versions in the long term. This makes absolute sense because the old PHP versions are left unmaintained, and it can compromise the security of their servers in case a vulnerability is discovered that affects these unmaintained PHP versions.

大多数共享和托管托管平台和 PHP PaaS 产品通常只提供当前的 PHP 版本，但长期不支持旧的 PHP 版本。这是绝对有意义的，因为旧的PHP版本是未维护的，并且如果发现影响这些未维护的PHP版本的漏洞，它可能会损害其服务器的安全性。

If the hosting provider/PaaS provider no longer supports the required PHP version, it might make sense to shop around for a provider that supports a wide range of PHP versions.

如果托管提供程序/PaaS 提供程序不再支持所需的 PHP 版本，则可能需要货比三家，寻找支持各种 PHP 版本的提供程序。

CloudLinux is one of the commercial operating systems that shared/managed hosting providers use on their servers, and those providers likely enable CloudLinux’s HardenedPHP feature. HardenedPHP is a feature in CloudLinux that the CloudLinux backports security fixes even after the official php.net team has marked a PHP version as EOL.

CloudLinux是共享/托管托管服务提供商在其服务器上使用的商业操作系统之一，这些提供商可能会启用CloudLinux的HardenedPHP功能。HardenedPHP是CloudLinux中的一个功能，即使在官方 php.net 团队将PHP版本标记为EOL之后，CloudLinux也会向后移植安全修复程序。

Another approach is maintaining a private server/cloud server and configuring it yourself. Maintaining a VPS/Cloud server comes with a maintenance burden, but most operating systems nowadays come with sane defaults, automatic updates, and more to take some of this burden away. However, this server maintenance may not be for everyone.

另一种方法是维护私有服务器/云服务器并自行配置。维护VPS /云服务器会带来维护负担，但如今大多数操作系统都有理智的默认值、自动更新等，以减轻一些负担。但是，此服务器维护可能并不适合所有人。

Debian LTS, Ubuntu LTS, Rocky Linux, and RHEL are a few Linux-based operating systems that provide PHP in their default repositories. They do not receive bug fixes from upstream, but security fixes are backported as applicable.

Debian LTS，Ubuntu LTS，Rocky Linux和RHEL是一些基于Linux的操作系统，在其默认存储库中提供PHP。他们不会从上游接收错误修复，但安全修复会向后移植（如果适用）。

For example, Ubuntu 20.04 LTS includes PHP 7.4.3 in its default repositories. Ubuntu 20.04 LTS receives hardware and maintenance updates until 2025. PHP 7.4 is currently marked as End-Of-Life by the official php.net team, but the developers behind Ubuntu 20.04 back-port any security patches to the PHP version available in the repository. Any non-security bug fixes are not back-ported. This essentially means that the PHP version of Ubuntu 20.04 will remain as PHP 7.4.3, but with all the security fixes applied. Ubuntu’s paid (free for five personal computers) Ubuntu Pro offering extends this with five additional years, which essentially means it is possible to securely run a PHP 7.4 application until 2030.

例如，Ubuntu 20.04 LTS 在其默认存储库中包含 PHP 7.4.3。Ubuntu 20.04 LTS 接收硬件和维护更新，直到 2025 年。PHP 7.4 目前被官方 php.net 团队标记为生命周期结束，但 Ubuntu 20.04 背后的开发人员将任何安全补丁向后移植到存储库中可用的 PHP 版本。

任何非安全错误修复都不会向后移植。这实质上意味着 Ubuntu 20.04 的 PHP 版本将保留为 PHP 7.4.3，但应用了所有安全修复程序。Ubuntu的付费（五台个人电脑免费）Ubuntu Pro产品将其延长了五年，这基本上意味着可以在2030年之前安全地运行PHP 7.4应用程序。

网络服务器集成

PHP integrates with web servers such as Apache, Nginx, Litespeed, Caddy, and more. When running a legacy PHP application, it is recommended to switch to php-fpm as the server API. Apache, for example, supports running PHP as an Apache module, which hinders the ability to upgrade the Apache version in case the application must be run on an older PHP version.

PHP与Apache，Nginx，Litespeed，Caddy等Web服务器集成。运行旧版 PHP 应用程序时，建议切换到 php-fpm 服务器 API。例如，Apache支持将PHP作为Apache模块运行，这阻碍了升级Apache版本的能力，以防应用程序必须在较旧的PHP版本上运行。

Nginx and Caddy only integrate with php-fpm, so no changes are necessary for them.

Nginx 和 Caddy 只与集成 php-fpm ，因此不需要对其进行任何更改。

PHP also has a built-in server. It is unlikely that a production server uses it, but make sure to use a fully-fledged web server to add a separation between PHP and the web server.

PHP 还有一个内置的服务器。生产服务器不太可能使用它，但请确保使用成熟的 Web 服务器来添加 PHP 和 Web 服务器之间的分离。

容器化 PHP

When running a full LTS operating system (such as Ubuntu LTS) is not viable, an alternative approach would be using containers to run the required PHP version.

当运行完整的 LTS 操作系统（如 Ubuntu LTS）不可行时，另一种方法是使用容器来运行所需的 PHP 版本。

With containers, the rest of the file system and networking are left intact unless explicitly allowed. The PHP-FPM process can run inside a container with minimal file system access (session storage, temp files, file uploads, etc allowed), FPM port (for web server integration), and database ports allowed, but everything else remain within the container.

对于容器，除非明确允许，否则文件系统和网络的其余部分保持不变。PHP-FPM 进程可以在容器内运行，具有最少的文件系统访问权限（允许会话存储、临时文件、文件上传等）、FPM 端口（用于 Web 服务器集成）和允许的数据库端口，但其他所有内容都保留在容器内。

PECL 扩展替换

Even if the operating system or a third-party repository provides PHP updates, it is unlikely that they offer security updates for EOL PHP extensions.

即使操作系统或第三方存储库提供 PHP 更新，他们也不太可能为 EOL PHP 扩展提供安全更新。

PECL extensions that connect with external services such as SSH, FTP, Email, LDAP, etc are better off with user-land PHP implementations of them. 与外部服务（如SSH，FTP，电子邮件，LDAP等）连接的PECL扩展最好使用它们的用户土地PHP实现。
Extensions offering cryptographic operations (mcrypt and openssl for example) are better replaced with newer extensions such as Sodium, or its user-land PHP polyfills. 提供加密操作的扩展（ mcrypt openssl 例如）最好替换为较新的扩展，例如 Sodium 或其用户空间 PHP polyfill。
PDF libraries (such as DomPDF) can be replaced with headless browsers or command-line tools such as wkhtmltopdf. PDF库（如DomPDF）可以用无头浏览器或命令行工具（如wkhtmltopdf）代替。
Image generation extensions (such as Imagick and GD) can be replaced with CDNs that offer image manipulation. 图像生成扩展（如 Imagick 和 GD）可以替换为提供图像处理的 CDN。

作曲家 LTS

Composer, PHP’s dependency manager recently bumped its minimum PHP version requirement. However, Composer 2.2 is an LTS version of Composer 2, which should be supported for at least the end of 2023.

作曲家，PHP的依赖管理器最近提高了其最低PHP版本要求。但是，Composer 2.2 是 Composer 2 的 LTS 版本，至少应在 2023 年底受支持。

Composer is fairly conservative when it bumps up its minimum required PHP version, so it should be relatively trouble-free even on older PHP versions.

Composer 在提高其所需的最低 PHP 版本时相当保守，因此即使在较旧的 PHP 版本上，它也应该相对无故障。

LTS 框架、库和本地分支

PHP Frameworks and libraries such as Laravel, and Nette tend to be fast-moving frameworks while Symfony and Slim are more conservative.

PHP框架和库，如Laravel和Nette往往是快速发展的框架，而Symfony和Slim则更为保守。

Although Laravel used to offer LTS releases that provided five years of security updates, recent Laravel versions only offer only one year of active support followed by a year of security fixes, so it might require manually porting security updates.
虽然Laravel曾经提供提供五年安全更新的LTS版本，但最近的Laravel版本仅提供一年的活动支持，然后是一年的安全修复，因此可能需要手动移植安全更新。
Recent Drupal versions (such as Drupal 10) require recent PHP versions. Drupal 7 continues to receive support at the moment, but there are free and commercial Drupal LTS projects that provide coordinated security releases even after they officially reach EOL. For Drupal 7, there is also BackDrop CMS that provides an easy upgrade path.
最近的Drupal版本（如Drupal 10）需要最新的PHP版本。Drupal 7 目前继续获得支持，但有一些免费和商业的 Drupal LTS 项目即使在正式达到 EOL 后也能提供协调的安全发布。对于Drupal 7，还有BackDrop CMS，它提供了一个简单的升级路径。
WordPress tries to maintain compatibility for older PHP versions, so updating to WordPress should be possible even on older PHP versions.
WordPress试图保持与旧PHP版本的兼容性，因此即使在较旧的PHP版本上也可以更新到WordPress。Symfony (and its components) provide LTS versions with at least three years of security updates.
Symfony（及其组件）为LTS版本提供至少三年的安全更新。

When a PHP library/framework abandons the version the PHP application depends on, it then becomes up to the maintainer of the PHP application to fork the repository and back-port security updates as they are made. Sharing that effort as a public project can pay forward the efforts others make maintaining other LTS packages. For private packages, a locally cloned repository or a private Composer repository can make the Composer integration work.

当 PHP 库/框架放弃 PHP 应用程序所依赖的版本时，PHP 应用程序的维护者将仓库分叉并在安全更新进行时向后移植。作为公共项目分享这些努力可以回报其他人维护其他 LTS 包的努力。对于私有软件包，本地克隆的存储库或专用 Composer 存储库可以使 Composer 集成正常工作。

articles origin：https://php.watch/articles/extend-lifetime-legacy-php