按框架、博客或商城找到 PHP2Shell 修复路径：确认实际 PHP、核对应用兼容性、解决升级障碍，最后验证 CVE-2026-109618 与 CVE-2026-109619 均已修复。
全部应用
Laravel
接手 Laravel 老项目先找回 composer.lock，再修改约束。Illuminate 组件应配套升级，逐个阅读跨越的大版本升级说明。Horizon、认证组件、Carbon、文件系统适配器要单独核对。首页打开不代表序列化队列任务兼容；切换前协调任务处理与代码版本，切换后替换并重启长驻工作进程。
阅读指南 ↗Symfony
Symfony 要核对整组组件和 Flex recipes，不能只看 framework-bundle。跨大版本前先在原分支处理弃用项。Doctrine、Twig、Messenger、认证器都可能阻挡升级，即使 PHP 已满足最低要求。先在演练环境重建容器，同时验证 HTTP 路由和控制台工作进程。
阅读指南 ↗ThinkPHP
ThinkPHP 5.0、5.1、6、8 需要分别评估迁移。核对 topthink/framework、独立 ORM 和模板包；直接复制 thinkphp 目录的项目可能没有锁文件。重点检查路由、中间件、旧行为扩展和自定义标签。不要在线上只覆盖框架目录，也不要把最低 PHP 要求当作 PHP 8 兼容保证。
阅读指南 ↗CodeIgniter
CodeIgniter 3 与 4 的应用结构不同，不能把 codeigniter4/framework 直接覆盖到 CI3 的 system/。先清点自定义核心类、hooks、会话驱动和路由。表格仅列 CI4 的具体发布样本，后期小版本会提高 PHP 要求。配置和业务代码应在副本迁移，再比较登录和数据库行为。
阅读指南 ↗Yii
先区分 Yii 1、Yii 2 与 Yii 3。yiisoft/yii2 样本只描述 Yii 2 的某个补丁，不代表所有 2.0 版本，更不代表 Yii 1。检查扩展、RBAC、ActiveRecord、widgets 和资源构建。跨框架世代需要修改应用，不能只改 Composer 约束。
阅读指南 ↗CakePHP
CakePHP 3.10.5 明确排除 PHP 8，样本 4.5.12 也限制 PHP 低于 8.4。跨大版本要逐个阅读 ORM 和应用迁移文档。检查 entity 方法签名、自定义 finder，以及独立的认证和授权插件。应执行代表性查询和表单提交，安装检查不能代替业务验证。
阅读指南 ↗Laminas / Zend Framework
Zend 老项目可能属于 ZF1、ZF2 或 ZF3，并混用独立组件。表格只描述 laminas-mvc 样本，不能推导全部 Zend 兼容性。在副本中使用迁移工具前清点命名空间、ServiceManager factories 和模块配置。停止维护的第三方模块单独处理，迁移后验证 API、会话和服务构造。
阅读指南 ↗Slim
Slim 3 到 4 不只是提高 PHP 版本，还涉及 PSR-7 实现、factory、容器集成和中间件顺序。当前 Slim 3 补丁样本不能代表早期 Slim 3 的最低要求。以实际锁文件为准，在目标 PHP 上验证错误中间件、认证、请求体解析和响应输出。
阅读指南 ↗Phalcon
Phalcon 是编译型 PHP 扩展，Composer 更新不能替你安装匹配的 phalcon.so 或 Windows DLL。5.9 文档要求 PHP 8.1 以上，但不是全部 ABI 和二进制包的认证。匹配 PHP 版本、架构、NTS/ZTS，重编译或安装受支持扩展，并同时核对 FPM 与 CLI 的加载情况。
阅读指南 ↗Hyperf
Hyperf 使用长驻进程，常依赖 Swoole 或 OpenSwoole。先对齐 hyperf/*、协程客户端和扩展 ABI。只重启反向代理会留下旧应用进程。应测试连接池恢复、队列消费者和定时任务，再按项目的平滑发布流程替换全部工作进程。
阅读指南 ↗WordPress
WordPress 核心、主题、插件分别有 PHP 要求。通过站点健康或 version.php 确定核心版本，把子主题、必须使用插件和 drop-in 纳入盘点。先更新并测试完整副本，再切换这个域名实际使用的 Web PHP。旧版核心允许的低 PHP 门槛，不是继续使用停止支持解释器的建议。
阅读指南 ↗WooCommerce
WooCommerce 需要 WordPress、PHP、支付插件、主题覆盖文件共同兼容。最终迁移要协调订单写入冻结，避免丢单。演练官方数据库更新、HPOS、Action Scheduler 和沙箱支付回调。只回退 PHP 不能撤销已经变更的 WooCommerce 数据库结构，也不能找回备份后新写入的订单。
阅读指南 ↗Drupal
Drupal 的 core、core-recommended、Drush 和贡献模块必须配套。跨大版本前清理自定义代码中的弃用 API，在副本演练数据库 update hooks 与配置导入。Drupal 7 不属于这里的 Drupal 8+ Composer 包范围。包声明的最低值也不能代替所有后续补丁的官方 PHP 支持政策。
阅读指南 ↗Joomla
使用 Joomla 已安装清单和升级前检查，分别确认核心、扩展和模板覆盖文件。沿官方大版本路径更新第三方插件。兼容插件可辅助过渡，但不能证明全部扩展兼容。文件和数据库一起备份，演练结构更新，再核对后台登录和多语言路由。
阅读指南 ↗Magento Open Source / Adobe Commerce
Magento 与 Adobe Commerce 要核对准确产品、补丁后缀及系统要求表，而不只看 Composer。搜索、数据库、缓存和消息队列版本都可能阻挡升级。审查自定义模块与索引器，构建经过测试的部署产物，按官方维护流程切换。重新开放订单前验证金额、异步订单和支付回调。
阅读指南 ↗PrestaShop
PrestaShop 的 composer.json 最低版本不是完整的官方测试范围。目标发行版的 PHP 支持表、Symfony、支付模块、主题和 overrides 应一起核对。先在数据库副本试跑 Update Assistant，核对多店铺和历史订单。回退必须包含配套文件与数据库；切回 PHP 选择器不会撤销数据库迁移。
阅读指南 ↗OpenCart
先识别 OpenCart 的具体发行来源和修改机制。OCMOD、VQMod、主题与市场扩展可能绑定特定大版本。startup 检查只有最低值，不代表兼容上限。演练官方应用与数据库迁移，恢复订单写入前核对结账、支付通知、邮件和 storage 路径。
阅读指南 ↗PHPCMS V9
PHPCMS V9 先按遗留应用接管，确定发行来源及二次开发。本次无法核实历史官网，因此不提供通用 PHP 范围。离线检查数据库驱动、mysql_*、GBK/UTF-8、自定义内容模型和模板标签。原地修复或迁移都要保留附件及文章 URL，不能只以首页能打开作为验收标准。 导出 PHPCMS 内容前，按实际数据库整理栏目 ID、模型 ID、自定义字段与附件引用，表前缀以本地为准。对照原站抽查详情页与生成路径。只迁文章正文可能丢失模型字段，也可能让图片仍指向旧服务器。
阅读指南 ↗DedeCMS / 织梦
原版 DedeCMS、商业发行版和 DedeBIZ 分支必须分开识别。当前织梦官网标注 PHP5.6+，不代表所有历史 5.7 安装包都适用。离线审查数据库类、自定义频道模型、模板和字符集。备份 archives 与 addon 表、uploads 和静态文章地址，不要把另一个品牌的发行版直接覆盖到经过修改的生产目录。 导出织梦前先清点主档案表和各启用频道的附加表，核对本地表前缀及关联键，同时保存作者、栏目关系、模板规则与静态生成路径。导入后对比记录数，并抽查带图片的完整文章；只导出 archives 可能遗漏扩展字段。
阅读指南 ↗Discuz! X
Discuz! X、UCenter、论坛插件要分别记录版本。官方仓库存在不同构建和编码，只写 X3.4/X3.5 无法承诺 PHP 兼容范围。以实际发行包的要求和升级说明为准，演练统一登录、用户同步、附件访问和数据库编码，并保留论坛与 UCenter 的完整配套回退副本。 Discuz 应把论坛与 UCenter 配套恢复到隔离环境，确认是否还有别的网站共用该 UCenter，保存附件存储和用户 ID 关系。最终迁移协调账号写入，再从每个关联应用测试登录；论坛首页正常不能证明共享账户数据一致。
阅读指南 ↗Typecho
Typecho README 给出选定标签的最低要求，不代表全部主题和插件都兼容。先检查插件 hooks、主题函数、数据库适配器和自定义路由。数据库与 usr/ 配套备份。按官方流程更新后对比永久链接、评论、Markdown 渲染和上传媒体。
阅读指南 ↗EC-CUBE
EC-CUBE 升级要配套核对 Symfony、Doctrine 和具体支付插件。修改 Composer 之前确定准确的 4.x 发行版及插件范围。app/Customize 二次开发与 Twig 模板可能独立出错。上线前演练数据库迁移、运费税额、日文文本和沙箱支付返回流程。
阅读指南 ↗TYPO3
TYPO3 核心和扩展约束必须同步评估。跨大版本前清点自定义扩展、Fluid、TypoScript 和站点配置。先在演练环境运行官方 Upgrade Wizards，同时验证后台编辑和前台。核心包的最低 PHP 要求不能证明所有扩展兼容，也不等于拥有延长支持服务。
阅读指南 ↗Shopware
Shopware 的小版本和补丁号与 PHP 一样重要。先盘点自定义 app、plugin 和 Symfony 依赖，再沿官方顺序更新。按需重建 Administration 与店铺资源，并重启消息消费者。在数据库副本测试搜索索引、结账和集成 API；Composer 能解出依赖不证明商店可以正常接单。
阅读指南 ↗排除 PHP2Shell 修复中的兼容障碍
无人维护的 PHP 老站如何修复 PHP2Shell
没有 PHP 开发人员，老站又必须修复 PHP2Shell？先恢复管理权、验证备份并识别运行时，再选择带补丁的 PHP、迁移或静态归档。
修复 PHP2Shell 时的 PHP 升级报错排查
排除阻碍 PHP2Shell 修复的废弃接口、依赖冲突、扩展缺失和网关错误。在带补丁的 PHP 上恢复业务，并核实两个 CVE 的修复证据。
修复 PHP2Shell 要核对哪些 PHP 兼容版本
表格是选定发布样本的原始要求，不代表整个大版本的兼容承诺。只写最低版本而没有上限，不证明兼容全部新 PHP。还需核对实际锁文件、扩展和厂商当前支持政策。
修复 PHP2Shell 前的只读盘点
在授权的工作副本中操作。这些命令只盘点 CLI 环境和锁定依赖，不会修补 PHP，也不验证 Web 运行时。prohibits 中的 PHP 版本仅用于举例比较，不是通用升级推荐。
核实 PHP2Shell 修复
应用兼容性、应用维护支持和 PHP 安全是三项独立检查。选择仍受支持且修复两个 CVE 的 PHP 分支，再验证 Web 工作进程、定时任务和全部副本。只更新框架或插件不会更换 PHP 解释器。
| PHP 分支 | 低于此版本的上游发行版 | 首个修复版本 | 安全支持结束 |
|---|---|---|---|
| PHP 8.5 | < 8.5.12 | ✓ 8.5.12 | 2029年12月31日 |
| PHP 8.4 | < 8.4.27 | ✓ 8.4.27 | 2028年12月31日 |
| PHP 8.3 | < 8.3.36 | ✓ 8.3.36 | 2027年12月31日 |
| PHP 8.2 | < 8.2.35 | ✓ 8.2.35 | 2026年12月31日 |
这些分支不会获得 PHP 项目常规版本更新。7.4、8.0、8.1 有最小源码回移植；厂商补丁状态需单独核实。 阅读指南 ↗