Drupal 12：变化内容与迁移时机

Drupal 12 定于 2026年12月7日那一周发布，而 Drupal 10 在 2026年12月9日走到生命周期终点。这两个日期就写在 Drupal 核心发布计划的同一页上，相隔不过两行，可是绝大多数正在运行 Drupal 10 站点的人两个都没注意到。新大版本的第一个 alpha 已经在 2026年9月2日打上标签，所以这次发布的形状现在是记录在案的事实，不再是猜测。

这场撞车就是全部故事。一个大版本发布，对站点所有者来说通常并不紧急，因为你可以在旧的大版本上坐一两年，等生态跟上来。这一次不同，旧的大版本在新版本发布的同一周停止收到安全公告，于是一个技术事件变成了一个带着合规锋刃的截止日期。

下面要讲的是 drupal.org 公布的日程、代码里实际改动了什么、新的平台门槛对主机提出了什么要求、三条现实的升级路径以及各自的费用区间，还有一份从12月倒推出来的计划。让人安心的部分先说：Drupal 大版本升级的大部分内容是删除，而不是重新发明。

Drupal 12 什么时候发布，我必须迁移吗？ Drupal 12.0.0 定于 2026年12月7日那一周发布，与 Drupal 11.5.0 一同推出。Drupal 10 在两天后，也就是 2026年12月9日走到生命周期终点，此后不再为它发布任何安全公告。Drupal 11 站点面对的是一次小升级。Drupal 10 站点必须先经过 Drupal 11.4 或更高版本，所以这项工作是两跳而不是一跳。

决定你未来半年的两个日期

发布经理会提前公布整个周期，这一轮的安排格外整齐。Drupal 11.4.0 在 2026年6月29日那一周落地，这次发布同时终结了 Drupal 11.2.x 和 Drupal 10.5.x 的安全支持。12.0.0-alpha1 的标签打在 2026年9月2日。测试版要求必须在 2026年9月11日前完成，12.0.0-beta1 与 11.5.0-beta1 排在9月14日那一周，候选版本排在11月9日那一周。

然后12月7日那一周会同时发生三件事。Drupal 12.0.0 发布，Drupal 11.5.0 一同发布，Drupal 11.3.x 和 Drupal 10.6.x 的安全支持结束。两天后，也就是 2026年12月9日，Drupal 10 整体走到生命周期终点，此后不会再有任何版本发布。

为什么 Drupal 10 和 Drupal 12 撞在同一周

这是政策，不是巧合。发布流程概览写明，大版本每两年在偶数年发布，并且每个大版本至少支持四年，直到再有两个大版本发布为止。Drupal 10.0.0 发布于 2022年12月15日。Drupal 11 在 2024年8月到来，Drupal 12 在 2026年12月到来，后者正是第二个后续大版本，而四年也已经过去。这个时钟严格按计划走到了头。

同一套政策也管着小版本。每个小版本支持一年，前半年提供缺陷修复和安全修复，后半年只提供安全修复。这就是为什么今天只有 10.6.x 还在收公告，也是为什么 11.5.0 一发布，11.3.x 就失去保护。

Drupal 11 不会因为 Drupal 12 开始而停下。在同一周发布 11.5.0，标志着政策所称的长期支持阶段开始：旧的大版本保留一个 API 对齐的小版本，转到 Symfony 的 LTS 发布上，并且每六个月收到一次范围逐步收窄的维护版本。drupal.org 没有公布 Drupal 11 的确定终止日期，不过它自己的已弃用扩展文档写着 Drupal 11 将支持到 2028年中期至后期。

还有多少站点留在 Drupal 10 上

数字是公开的，而且不好看。drupal.org 的核心使用统计显示，在 2026年8月23日开始的那一周，共有 468,877 个站点报告了核心版本。其中 205,568 个站点在 Drupal 10 的某个分支上，168,857 个在 Drupal 11 上。已报告安装基数中大约 44% 落在12月停止收到公告的那个版本上。

更尖锐的数字藏在这个数字里面。只有 10.6.x 还有安全覆盖，而 10.6.x 占了其中 139,911 个站点。剩下的 65,657 个站点在 10.0 到 10.5 之间，也就是说它们今天，在这个9月，就已经跑在一个不受支持的小版本上，根本不用等到12月。

这些计数来自通过 Update Status 模块自愿上报的站点，所以真实规模更大，而倾斜方向一样。务实地读，就是会有非常多的组织想在同一个季度预约同一批升级工作，而10月和11月的瓶颈将是服务商的产能，而不是代码。

生命周期终点对一个 Drupal 站点究竟意味着什么

生命周期终点不是一个把站点弄坏的开关。你的 Drupal 10 安装在12月10日照样会像12月8日那样正常出页面。变化在于 Drupal 安全团队不再为那份代码发布公告和补丁，所以从那天起，Drupal 10 核心中每一个新发现的漏洞都会永久敞开。

第二个效应更慢，破坏力更大。贡献模块的安全覆盖取决于该模块在受支持的核心分支上有稳定版本，所以当维护者陆续放弃 Drupal 10 兼容时，你站点上的模块也会悄悄退出公告流程。发生这件事时你不会收到通知。模块只是不再出现在安全发布里，而你自己站点上的可用更新报告看起来依然是绿的。

第三个效应是，越拖出口越贵。一个在11月升级的 Drupal 10 站点，面对的是仍在维护的核心分支和一条可用的更新路径。同一个站点如果拖到第二年6月再升级，那就是一个抢救项目，因为它依赖的贡献模块又多走了六个月，而没有带上它。

Cyber Essentials、保险与合同条款

到这里，一个不受支持的 CMS 就不再只是工程问题了。NCSC 的 IT 基础设施 Cyber Essentials 要求 v3.3日期为 2026年4月，规定范围内设备上的所有软件都必须有授权且受支持，一旦失去支持就必须从设备上移除，或者用一个禁止一切进出互联网流量的既定子集把它移出范围。该控制项适用于服务器、IaaS、PaaS 和 SaaS，所以装在范围内服务器上的 Drupal 是正面命中的。

一个面向公众的 Drupal 10 站点不可能被隔离在互联网之外，所以 2026年12月9日之后可选的答案只有两个：升级它，或者接受它通不过那条控制项。如果你的组织持有 Cyber Essentials 或 Cyber Essentials Plus 并且每年续证，这就是下一次评估时会被书面问到的问题。

超出这一点的说法要谨慎。某一份网络保险保单或客户合同是否受影响，完全取决于其措辞，而真正起作用的条款通常是要求使用受支持软件或厂商支持版本的那一类，而不是点名 Drupal 的条款。请在12月之前而不是出事之后，读一遍自己的保单和主服务协议，那才是便宜的时候。

Drupal 12 究竟有什么不同

几乎没有不同，这是诚实而且有用的答案。12.0.0-alpha1 发布说明说得很直白：12.0.x 将与 11.5.x 几乎完全相同，区别只在于删除了已弃用代码（包括整个已弃用模块）、把依赖更新到新的大版本、以及提高了系统要求。至于其他所有改动，说明让你去读 11.5.x 分支。

确实有几处值得知道的行为变化。默认的密码哈希算法切换为 argon2id，在 argon2 不可用的环境里可以通过内核参数改用 bcrypt。核心的 robots.txt 现在会屏蔽带查询参数的搜索结果页，从而阻止搜索引擎抓取无穷无尽的分面组合，而自定义过 robots.txt 的站点需要手工补上那些 disallow 规则。核心已经内置的 HTMX 在 beta1 里从版本 2 升到版本 4。

还有一条容易漏掉。在生产环境中直接把 Drupal 托管在 Windows 上，在 Drupal 12 中被标为弃用，理由是没有自动化的 Windows 测试环境，在上面做测试的开发者也很少。本地开发用 Windows 仍然受支持。如果你的生产环境跑在 Windows 上，这是一个要在未来几个月内做出的主机决定，而不是一次代码修改。

离开核心的扩展

Drupal 多年来一直在把用途狭窄的模块从核心搬到贡献项目，Drupal 12 继续了这件事。alpha1 说明列出 Ban、Contact、Field Layout、History、Settings Tray、Shortcut 和 Telephone 被移除，同时移除的还有 Stable 9 主题。Text with Summary 字段插件也搬去了自己的贡献模块。Ban 早在 11.3 就被弃用，Contact、Field Layout、History 和 Telephone 在 11.4，Settings Tray、Shortcut 和 Text with Summary 在 11.5。

其中两个会让人意外。Shortcut 和 Settings Tray 是非常多编辑团队每天都在用、却从没把它们当成可选项的管理功能，尤其 Settings Tray 支撑着内容编辑依赖的区块就地配置。

比这份清单更重要的是处理它的手法。正确的动作是在升级之前把贡献版本加进 Composer 依赖，而不是卸载模块。卸载会销毁该扩展的配置，而 Drupal 的模块发现最后才看核心，所以只要贡献项目在，Drupal 自然会用它。还要注意 Drush 可以绕过 update.php 上关于扩展缺失的警告，于是故障会在事后以状态报告里的错误形式冒出来。

失去 Migrate Drupal 才是咬得最狠的改动

Migrate Drupal 和 Migrate Drupal UI 两个模块在 Drupal 12 中被移除，而且与其他模块不同，它们不会被搬到贡献项目里。Drupal 12 保留了 Migrate API 和面向现代 Drupal 的目标插件，但没有保留 Drupal 6 和 Drupal 7 的源插件。

如果你手上有一个 Drupal 7 站点，请把这句再读一遍。那套读取旧版 Drupal 数据库并写入现代 Drupal 的工具，在 Drupal 11 里存在，在 Drupal 12 里不存在。drupal.org 的指引很明确：打算使用迁移 API 的 Drupal 6 或 Drupal 7 站点，应当继续迁移到 Drupal 11，然后用常规的更新流程从 Drupal 11 走到 Drupal 12。

这就把一个模糊的打算变成了一条硬性的顺序约束。一个落在 Drupal 11 退出支持之后的 Drupal 7 重建项目，只能自己写源插件，或者在一次性环境里还原一个旧核心来跑迁移，或者用别的手段把内容导出再导入。这三条都比在 Drupal 11 还是当前受维护目标时就把迁移做掉更贵。这类工作的形状，我们在Drupal 迁移的费用、选项与截止日期一文里讲得更细。

新的依赖门槛

大版本正是 Drupal 被允许抬高平台要求的地方，而 Drupal 12 把这份许可全线用了个遍。这些门槛是你没法讨价还价的部分，因为它们在安装时就被强制执行。

PHP 8.5，再旧的都不行

Drupal 12 要求 PHP 8.5。PHP 要求对照表显示 Drupal 12.0 支持 PHP 8.5 并拒绝一切更低版本，而 Drupal 11.3 和 11.4 接受 8.3、8.4 和 8.5。那段重叠就是你的迁移通道：先在 Drupal 11.4 上把站点挪到 PHP 8.5，确认行为正常，然后再动 Drupal。

这个门槛与其说苛刻，不如说宽裕。PHP 8.5 于 2025年11月20日发布，php.net 的受支持版本页面把它的活跃支持列到 2027年12月31日，安全支持列到 2029年12月31日。落在这上面，可以买到三年时间才需要再谈这件事。

数据库与 Symfony

Drupal 12 的数据库服务器要求是 MySQL 8.0 或更高、MariaDB 10.11 或更高、PostgreSQL 18 或更高，以及带 json1 扩展的 SQLite 3.45。使用 PostgreSQL 的站点应当把这条门槛当作最需要仔细核对的一条，因为 alpha1 发布说明写的是 PostgreSQL 19，而要求页面和安装程序代码写的都是 18。在预约数据库工作之前，请在 beta1 时再核对一次。

在底层，Symfony 从 7.4 升到 8.1，Guzzle 从 7 升到 8。若干旧的库大版本被放弃支持，包括 doctrine/lexer 2、egulias/email-validator 3 和 guzzlehttp/psr7 2。直接对 Symfony 类做类型提示的自定义代码，就是这件事显形的地方。

这些门槛对主机提出了什么

真正卡住共享主机和托管主机的是 MariaDB 的抬升。Drupal 11 接受 MariaDB 10.6，而按照 MariaDB 维护政策，它的社区维护已在 2026年7月6日结束，所以一个 Drupal 11 站点眼下完全可以名正言顺地跑在一个不受支持的数据库引擎上。Drupal 12 把门槛抬到 10.11，而这一版维护到 2028年2月16日。如果你的主机今天拿不出 PHP 8.5 和 MariaDB 10.11，那么换主机必须排在换 Drupal 之前，而正是这种顺序调换，把一件两周的活变成两个月的活。平台这一侧，我们在什么才真正跑得动 Drupal里做了梳理。

弃用模型为什么让 Drupal 12 变得可控

这里有一个几乎从没被解释给站点所有者听的机制，而它正是 Drupal 大版本不再吓人的原因。跨大版本连续升级政策让核心做出一个简单承诺：下一个大版本拥有与上一个大版本最后一个小版本相同的公开 API。新 API 在小版本里加入，旧 API 在小版本里被标记为弃用，而删除只发生在大版本的边界上。

其务实的后果值得用大白话说清楚。如果你的自定义代码和贡献模块能在 Drupal 11.5 上运行且没有弃用警告，那它们就能在 Drupal 12 上运行。升级不再是重写，而变成一次依赖抬升加一次数据库更新，因为所有会坏掉的东西，几个月前就已经作为警告报给你了，而你本可以从容修掉。

这也是发布说明让你先升到 11.4 或更高、并强烈建议 11.5 的原因。来自 11.4.0 之前版本的数据库更新路径已经被从 Drupal 12 里整个移除，所以 11.3 或更早的站点在沿着 11 分支往上走之前，根本没有通往 12 的路。这不是建议，这是一条缺失的代码路径。

报告弃用情况的工具

干这件事的项目有两个，而且都还在维护。Upgrade Status 是全站扫描器。你要把它装在准备升级的那个站点上，而不是升级之后的站点上，因为被弃用的 API 必须还在，它才能找到对这些 API 的调用。它会检查你的环境是否满足下一个大版本的系统要求，把你的贡献项目与可用更新做交叉比对，针对弃用的 PHP API 用法运行 PHPStan，并读取 Twig 模板、info.yml 文件、composer.json 和已弃用的配置键。2026年7月2日发布的 5.0.0-alpha3 声明兼容 Drupal 10.4、11 和 12。

它还会给发现的问题分类，而这一点最省钱。问题被分成机器能修的和必须由人来修的，于是你可以在承诺日期之前先把人工那一半算出价钱。它在 Drush 下以 upgrade_status:analyze 运行，其 Code Climate 格式的 JSON 输出可以接进 GitLab CI。

另一半是 Drupal Rector。它会改写你的自定义模块和主题中可以机械修复的弃用调用，还有一个 --dry-run 参数可以先看差异。版本 1.1.2 发布于 2026年8月7日。两者配合，一位称职的开发者可以在两到三天内为一个中等规模站点拿出一份站得住脚的就绪报告。

路径一：从 Drupal 11 到 Drupal 12

如果你在 Drupal 11.4 或 11.5 上，而且贡献模块都是新的，这就是一件小活。官方升级指南基本上就是一串 Composer 命令：用 --no-update 声明版本 12 的元包，删掉任何显式的 drupal/core 依赖，跑 composer update --dry-run，然后真跑一遍，再用 drush updatedb 应用数据库更新。

真正的工作在这前后两端。之前要跑 Upgrade Status，为你确实在用的、已被移除的核心扩展加上贡献替代品，并确认主机提供 PHP 8.5。之后要预料到每一个核心脚手架文件都变了，包括 .htaccess，所以你对它们做过的自定义必须有意识地重新应用，而不是盲目合并。

当依赖拒绝求解时，composer why-not drupal/core ^12 会点名拦路的那一个。在 composer.json 里允许一个模块的两个大版本，例如 "^6.1 || ^7.0"，是给处在过渡期的项目搭桥的标准做法。如果你需要的模块有可用补丁但还没有打标签的发布，Drupal Lenient Composer 端点正是为此存在，而且仍在维护。

路径二：从 Drupal 10 到 Drupal 12 是两跳

不存在从 Drupal 10 直接升到 Drupal 12 的路径。Upgrade Status 的文档说得很明确，而 11.4 之前数据库更新路径的移除让这条规则被强制执行。你要先从 Drupal 10.6 走到 Drupal 11.4 或 11.5，验证站点，然后再从那里走到 Drupal 12。

只要计划得当，这并不是双倍的工作量。从 Drupal 10 到 Drupal 11 那一跳承担了几乎全部风险，因为贡献模块的兼容问题住在那里，自定义代码撞上被移除 API 的地方也在那里。第二跳就是上面说的那件小活。想把两跳压进同一个变更窗口的团队，通常最后分不清是哪一跳弄坏了什么。

行得通的顺序是：现在就做 Drupal 11 那一跳，让站点在 11.4 或 11.5 上跑几个星期，好让真实的编辑行为和流量把异常暴露出来，然后等贡献模块针对 Drupal 12 打出稳定版本后，在新年里再取 Drupal 12。关键是要在12月之前完成第一跳，因为正是这一跳把你从不受支持的代码里带出来。

路径三：Drupal 7 或 8 是重建，不是升级

任何比 Drupal 9 更旧的东西都是另一回事。Drupal 7 在 2025年1月5日走到终点，Drupal 6 在 2016年2月。两者都完全不能原地升级，因为它们早于现代架构本身。它们要被迁移，也就是在当前 Drupal 上建一个新站点，再用 Migrate API 把内容搬进去。Drupal 8 站点技术上确实有一条原地路径，但那条路要连着穿过四个大版本，而每一个贡献模块都得在每一步中活下来，所以通常把它当作重建反而更省钱。

费用是由内容之外的一切主导的。主题要重做，自定义模块要针对一套完全不同的 API 重写，各种集成要重新接上。按我们的经验，内容迁移本身通常是预算里较小的那一半，这与大多数所有者来问报价时的预期恰好相反，也正是我们把这类项目按网站开发而不是按升级来定范围的原因。

对这些站点来说，12月的截止日期以另一种方式起作用，但因为 Migrate Drupal 被移除，它照样咬人。你的目标必须是 Drupal 11 而不是 Drupal 12，而按照 drupal.org 自己的文档，Drupal 11 支持到 2028年中期至后期。这给了 Drupal 7 的所有者一个真实的窗口，但那是一个有硬边界的窗口，而为了赶上一个 2028年的目标，在 2028年才开始一个六个月的重建，算不上计划。

每条路径在英国要花多少钱

这些是我们自己交付经验里的内部估算，不是公开报价，而每个区间内部的跨度几乎完全由贡献模块的健康状况决定，而不是站点规模。英国服务商做这类工作的日费大约是 600 到 900 英镑。维护良好的站点从 Drupal 11 升到 12，含测试是三到八天，落在大约 2,000 至 6,000 英镑。同一个站点如果贡献模块已经陈旧，就要预留两到四周和 6,000 至 12,000 英镑。

Drupal 10 站点要付两跳的钱。维护良好的话，Drupal 10 到 11 那一跳是 6,000 至 15,000 英镑，Drupal 12 那一跳再加 2,000 至 6,000 英镑，于是四到八周内合计 8,000 至 21,000 英镑。若长期失修，仅第一跳就要 15,000 至 35,000 英镑，总额落在 17,000 至 41,000 英镑之间。Drupal 7 重建是三到六个月，常见 40,000 至 120,000 英镑，规模大或改造重的站点还会更高。

决定你日期的是贡献模块盘点

升级项目很少死在核心上。它们死在名单里第十四个模块上，那个谁都记不起来是什么时候装的模块，它没有兼容下一个大版本的发布，而维护者上一次留言是在2023年。在你承诺日期之前先做这次盘点，因为正是这次盘点产出那个日期。

跑一遍 Upgrade Status 并导出报告，然后把模块分成四个桶。第一个桶是有稳定版本支持目标大版本的项目，它们不花钱。第二个桶是问题队列里有补丁或开发版本的项目，它们要花一点集成工作，并且带着补丁最终没被合入的风险。第三个桶是有开放问题但没有补丁的项目，需要有人去写。第四个桶是完全没有任何活动的项目。

定下时间表的是第四个桶，而它的大小今天就能知道，不必等到11月。一个有三十个贡献模块、第四个桶为空的站点，是一件顺当的工作。同一个站点如果第四个桶里有四个模块，那就是预算完全不同的另一份委托，而这两份报价之间的差别，只值一天的扫描。

遇到被弃养的模块该怎么办

诚实的选项有四个，选哪个取决于这个模块在做什么。如果它提供的功能已经没人用了，就移除它，在多年编辑口味漂移之后，这比团队预想的更常成立。或者换成一个做同样事情、仍在维护的项目，并接受随之而来的配置迁移。

接手维护，在 Drupal 里这是一个真实的选项，也没有听起来那么吓人。drupal.org 有一套成为无人支持项目维护者的成文流程，而对一个你的业务确实依赖的小模块来说，把它领养下来可能比替换更便宜。这笔成本是持续的而不是一次性的，所以要老实地把它算进去。

或者，把这个行为在一个只覆盖你实际用到的范围的自定义模块里重新实现一遍。贡献模块为所有人解决通用问题，而你通常只需要其中窄窄的一片。针对当前 API 把那一片重做，往往是两天的活对上两周的移植，而且能永久去掉这个依赖。怎样甄别具备这种判断力的人，我们在聘请 Drupal 开发者一文里讲过。

从 2026年12月9日倒推的时间表

从终点日期出发，计划会自己写出来。到9月下旬，在生产环境的一份副本上针对 Drupal 12 跑一遍 Upgrade Status，把那四个桶落到纸上。这是两到三天的工作，而它是唯一能让你诚实地为其他一切定价的产出物。

到10月中旬，确认你的主机能提供 PHP 8.5 和那些数据库门槛，如果不能就开始搬。同时把贡献模块的那些问题定下来，因为它们每一个都带着前置周期。到11月上旬，Drupal 10 站点应当已经完成到 Drupal 11.4 或 11.5 的升级，并且站点已经在新分支上跑生产。

到12月初，你会是在观看 12.0.0 发布，而不是被它推着反应。如果那时你在 Drupal 11 上，就等贡献项目针对它打出稳定版本后，在 2027年1月或2月再取 Drupal 12。在发布当周升级并没有奖品，而 Drupal 11.5 那时仍在支持期内。奖品属于在公告停止时不在 Drupal 10 上的人。

什么都不做的代价

直接代价是，2026年12月9日之后披露的每一个 Drupal 核心漏洞，都会在你的站点上永久敞开。Drupal 的公告史里有过严重到发布数小时内就被利用的远程代码执行问题，而公网 IP 上一个未打补丁的 CMS，是被自动扫描找到的，不是被某个专门挑中你的攻击者找到的。

间接代价来得更早，而且通常更大。在 Cyber Essentials 评估中通不过受支持软件那条控制项，可能影响你参与要求该认证的合同的资格，而这在英国公共部门采购里很常见。贡献模块会停止为你的分支发修复。而升级本身每个月都在变贵，因为哪怕没人动过任何东西，你的代码库与受维护生态之间的差距也在拉大。

还有一种更安静的代价。一个谁都不被允许升级的站点，往往会变成一个谁都不被允许改动的站点，功能开发因此停摆，因为每一处改动都得建立在一套即将消失的 API 之上。一个五年历史的 Drupal 站点，就是这样从升级变成重建的。如果你正在掂量这个决定，我们的 Drupal 开发指南会比一份报价更适合当起点。

两个可以正当等待的理由

等待在两种情况下站得住脚，而且必须是有意识地等。第一种是你已经在 Drupal 11.4 或 11.5 上。这些分支受支持，它们就是为 Drupal 12 设计的发射台，而在贡献项目还在陆续打标签的头几周里去取一个崭新的大版本没有任何好处。等到 2027年第一季度是专业的选择，不是偷懒的选择。

第二种是一个已经有预算、也已经排期的 Drupal 7 重建。把 Drupal 7 迁到 Drupal 11 再立刻推进 Drupal 12 是多余动作。落在 Drupal 11 上，跑起来，之后再把 Drupal 12 当作日常维护取走。

站不住脚的是，在没有既定计划的情况下继续坐在 Drupal 10 上。如果这说的是你，那么到9月底最低限度应有的状态是：一份扫描报告、一个点名的目标分支，以及日历上的一个日期。其余一切都还可以调整。如果你希望由做过这件事的人来出这份评估，我们的软件开发团队把版本审计当作范围固定的一项工作来做。

从哪里开始

先做扫描。世上几乎每一份糟糕的 Drupal 升级报价，都是在没有扫描的情况下做出来的，这也是为什么其中那么多在两个方向上都是错的。两到三天的 Upgrade Status 与 Drupal Rector 输出，会告诉你自己实际落在上面五个费用区间的哪一个，而这一个数字对你和董事会谈话的改变，胜过任何关于大版本的泛泛之谈。

Mecanik 做这类审计，也做随后的升级，既面向正在直面12月的 Drupal 10 站点，也面向计划在 2027年从容迁移的 Drupal 11 站点。自定义模块工作、集成和弃用清理归我们的软件开发团队，而重建或换主机则归网站开发。如果这件事落到你桌上是因为安全态势，先读我们关于 Drupal 安全公告与真实风险的文章；如果版本迁移期间的自然流量才是你的担忧，那么 Drupal SEO 配置那一篇讲的正是要保护什么。

常见问题

Drupal 12 什么时候发布，Drupal 10 什么时候走到生命周期终点？ Drupal 12.0.0 定于 2026年12月7日那一周发布，与 Drupal 11.5.0 一同推出，而 Drupal 10 在 2026年12月9日走到生命周期终点。两个日期都公布在 Drupal 核心发布计划上。同一周内，11.3.x 与 10.6.x 两个小版本分支的安全支持也会结束。Drupal 12.0.0-alpha1 已在 2026年9月2日打上标签。

我可以从 Drupal 10 直接升级到 Drupal 12 吗？ 不可以。来自 Drupal 11.4.0 之前版本的数据库更新路径已经从 Drupal 12 中移除，所以 Drupal 10 站点必须先升到 Drupal 11.4 或更高，然后再升到 Drupal 12。drupal.org 建议在大版本迁移之前先到 11.5.0 或更高。请按两跳来规划，其中从 Drupal 10 到 11 那一跳承担了几乎全部风险和成本。

Drupal 12 的系统要求是什么？ Drupal 12 要求 PHP 8.5，并放弃对 PHP 8.4 及更早版本的支持。数据库门槛是 MySQL 8.0、MariaDB 10.11、PostgreSQL 18，以及带 json1 扩展的 SQLite 3.45。Symfony 升到 8.1，Guzzle 升到 8.0。在生产环境中直接把 Drupal 托管在 Windows 上已被弃用，不过本地开发使用 Windows 仍然受支持。

与 Drupal 11.5 相比，Drupal 12 究竟有什么新东西？ 按设计几乎没有。alpha1 发布说明写明，12.0.x 除了移除已弃用代码、更新依赖大版本和抬高系统要求之外，与 11.5.x 几乎完全相同。值得注意的行为变化是默认密码哈希算法改为 argon2id、HTMX 升到版本 4，以及核心 robots.txt 会屏蔽带查询参数的搜索结果页。

在英国做一次 Drupal 12 升级要花多少钱？ 在维护良好的 Drupal 11 站点上，是三到八天的工作，按英国服务商每天 600 至 900 英镑的常见费率，大约 2,000 至 6,000 英镑。Drupal 10 站点要付两跳的钱，维护良好时落在 8,000 至 21,000 英镑，长期失修时落在 17,000 至 41,000 英镑。Drupal 7 重建是三到六个月，常见 40,000 至 120,000 英镑。这些是内部估算，不是公开报价。