PHP 正在稳步发展。每年都会有一个主要的新版本发布，其中包含新功能、性能改进、相当一部分弃用，甚至语法更改。PHP 核心开发人员维护两个最新的 PHP 版本，其中包括主动错误修复和安全修复，然后是安全修复。这实际上意味着每个主要的 PHP 版本将最多支持三年，并且现有的 PHP 应用程序将被迫升级。
虽然更新现有的 PHP 应用程序是理想和推荐的方法，但不可避免地，有些应用程序/网站无法证明更新的人力、政治和财务成本是合理的。对于在 PHP 5 系列或 PHP 7 系列上运行的遗留 PHP 应用程序尤其如此。例如，WordPress.org报告称，只有 16% 的报告 WordPress 站点在PHP 核心开发人员支持的 PHP 版本上运行。
更新 PHP 应用程序以与最新的 PHP 版本兼容存在很多困难。这可以从不需要或需要很少的更改到感觉像是完全重写的范围。十多年前开发的 PHP 应用程序构成了最大的挑战，因为它们往往使用不再受支持的 PHP 扩展，没有类型支持，并且通常也没有自动测试来验证更改。
Rector等工具可以自动执行一些（如果不是大部分）必要的更改，但是非常旧的 PHP 版本往往需要大量手动代码更新。
在某些情况下，升级成本得不偿失。其中一些示例包括仅在专用网络中使用的内部应用程序、计划重写的应用程序以及原始开发人员不再在公司工作的应用程序。实际上，这些应用程序可能永远不会更新；只是最终被取代。
由于 PHP 版本最多只能接收三年的官方更新，这可能会使应用程序容易受到安全漏洞的攻击，这些漏洞通常也会影响这些未维护的 PHP 版本。PHP 平台即产品 (PAAS) 产品和共享托管服务提供商也强制更新到最新的 PHP 版本，这也可能导致应用程序在新的 PHP 版本上崩溃。
本文讨论在安全的 PHP 环境中运行遗留 PHP 应用程序的策略，以及额外的安全预防措施和维护，从而延长所述 PHP 应用程序的生命周期。
PHP 应用程序越多地锁定在 PHP 版本中，它更新的速度就越快。然而，与更新已有数十年历史的 PHP 应用程序相比，将遗留应用程序再保留几年直到被替换有时更现实可行。
共享主机和平台到私人服务器
大多数共享和托管托管平台和 PHP PaaS 产品通常只提供当前的 PHP 版本，但长期不支持旧的 PHP 版本。这是绝对有道理的，因为旧的 PHP 版本无人维护，如果发现影响这些无人维护的 PHP 版本的漏洞，它可能会危及服务器的安全性。
如果托管提供商/PaaS 提供商不再支持所需的 PHP 版本，货比三家，寻找支持各种 PHP 版本的提供商可能是有意义的。
CloudLinux 是共享/托管托管提供商在其服务器上使用的商业操作系统之一，这些提供商可能启用CloudLinux 的 HardenedPHP功能。HardenedPHP 是 CloudLinux 中的一项功能，即使在官方 php.net 团队将 PHP 版本标记为 EOL 之后，CloudLinux 也会向后移植安全修复程序。
另一种方法是维护私有服务器/云服务器并自行配置。维护 VPS/云服务器会带来维护负担，但如今大多数操作系统都具有合理的默认设置、自动更新等功能，可以减轻一些负担。但是，此服务器维护可能并不适合所有人。
Debian LTS、Ubuntu LTS、Rocky Linux 和 RHEL 是一些基于 Linux 的操作系统，它们在其默认存储库中提供 PHP。他们不会从上游接收错误修复，但会在适用时向后移植安全修复。
例如，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 与 Apache、Nginx、Litespeed、Caddy 等 Web 服务器集成。运行遗留 PHP 应用程序时，建议切换php-fpm为服务器 API。例如，Apache 支持将 PHP 作为 Apache 模块运行，这阻碍了升级 Apache 版本的能力，以防应用程序必须在较旧的 PHP 版本上运行。
Nginx 和 Caddy 只与 集成php-fpm，因此不需要对它们进行任何更改。
PHP 也有一个内置的服务器。生产服务器不太可能使用它，但请确保使用成熟的 Web 服务器来添加 PHP 和 Web 服务器之间的分离。
容器化 PHP
当运行完整的 LTS 操作系统（例如 Ubuntu LTS）不可行时，另一种方法是使用容器来运行所需的 PHP 版本。
对于容器，文件系统和网络的其余部分将保持不变，除非明确允许。PHP-FPM 进程可以在具有最小文件系统访问权限（允许会话存储、临时文件、文件上传等）、FPM 端口（用于 Web 服务器集成）和数据库端口的容器内运行，但其他一切都保留在容器内.
PECL 扩展替换
即使操作系统或第三方存储库提供 PHP 更新，它们也不太可能为 EOL PHP 扩展提供安全更新。
- 与外部服务（如 SSH、FTP、电子邮件、LDAP 等）连接的 PECL 扩展与它们的用户态 PHP 实现相得益彰。
- 提供加密操作（
mcrypt和openssl例如）的扩展最好替换为更新的扩展Sodium，例如 或其用户级 PHP polyfill。 - PDF 库（例如 DomPDF）可以替换为无头浏览器或命令行工具，例如wkhtmltopdf。
- 图像生成扩展（例如 Imagick 和 GD）可以替换为提供图像处理的 CDN。
Composer长期支持
Composer，PHP 的依赖管理器最近提高了它的最低 PHP 版本要求。但是，Composer 2.2是Composer 2的 LTS 版本，应该至少在 2023 年底得到支持。
Composer 在提高其最低要求的 PHP 版本时相当保守，因此即使在较旧的 PHP 版本上也应该相对没有问题。
LTS 框架、库和本地分支
Laravel 和 Nette 等 PHP 框架和库往往是快速发展的框架，而 Symfony 和 Slim 则更为保守。
- 尽管Laravel过去提供提供五年安全更新的 LTS 版本，但最近的 Laravel 版本仅提供一年的有效支持和一年的安全修复，因此可能需要手动移植安全更新。
- 最新的Drupal版本（例如 Drupal 10）需要最新的 PHP 版本。Drupal 7 目前继续获得支持，但也有免费和商业的 Drupal LTS 项目即使在正式达到 EOL 后也能提供协调的安全版本。对于 Drupal 7，还有BackDrop CMS提供了一个简单的升级路径。
- WordPress试图保持对旧 PHP 版本的兼容性，因此即使在旧 PHP 版本上也应该可以更新到 WordPress。
- Symfony（及其组件）提供至少三年安全更新的 LTS 版本。
当 PHP 库/框架放弃 PHP 应用程序所依赖的版本时，PHP 应用程序的维护者就会在创建时分叉存储库并向后移植安全更新。作为一个公共项目分享这项工作可以回报其他人为维护其他 LTS 软件包所做的努力。对于私有包，本地克隆存储库或私有 Composer 存储库可以使 Composer 集成工作。
