结论先说：WordPress 7.2 预计 2026 年 12 月初发布，这一版的重心不是新花样，而是安全底座与样式确定性——sudo 模式、 Secrets API 、应用密码加固三项安全工程领衔，同时带来目录区块、表单全局样式、可扩展站点编辑器，以及一个新的默认主题 Ipsum 。官方已明确提醒：路线图上的内容是「正在推进」，并不保证每一项都会进入最终版本，所以站点主现在该做的不是等升级，而是提前做兼容性准备。
官方路线图到底说了什么
这份《 Roadmap to 7.2 》由 WordPress 核心团队发布在 make.wordpress.org/core（2026-09-18），把 7.2 的工作分成 Accessibility 、 AI 、 Admin 、 Blocks & APIs 、 Collaboration 、 Design & Editor 、 Media 、 Performance 、 Security 等几条线。要点如下：
- 发布时间：WordPress 7.2 计划于 2026 年 12 月初发布。
- 协作方向：Notes（批注）成为重点，新增「建议（suggestions）」与 emoji 表情回应，让协作更直接、更互动。
- 安全方向：sudo 模式（敏感操作前重新验证身份）、 Secrets API（提供存储凭据的一等公民方案）、应用密码（Application Passwords）加固。
- 样式方向：可在全局样式（Global Styles）里直接改表单元素、响应式样式与自定义状态支持扩展、单个区块能正确继承全局设置。
- 区块库：新增 Description List（描述列表）区块，以及呼声很高的 Table of Contents（目录）区块。
- 日常体验：修复一批写作小毛病、错误信息更清晰并带「复制」按钮、媒体插入器与弹窗继续打磨。
- 后台图标：管理栏与菜单换成一套 SVG 图标，替代 dashicons，渲染更稳定、对辅助技术更可预期。
- 可扩展站点编辑器：插件作者首次可以注册自己的界面与设置项。
- 新默认主题：随版本附带一个名为 Ipsum 的默认主题，定位是「刻意极简的空白画布」，方便在此基础上做自己的设计。
三项安全工程：7.2 最值得关注的部分
如果说 7.1 偏向编辑体验，7.2 明显把重量压在了安全上。三项工作的定位差别如下：
| 工程 | 解决什么问题 | 对站点主的影响 |
|---|---|---|
| sudo 模式 | 敏感操作（如改关键设置、凭据相关动作）缺少二次身份确认 | 操作多一步重新验证，但被劫持会话的危害面变小 |
| Secrets API | 第三方插件各自用不同方式存 API Key / Token，容易写进数据库明文 | 凭据存储有统一的一等公民方案，插件间行为趋于一致 |
| 应用密码加固 | Application Passwords 在自动化场景被广泛使用，攻击面变大 | REST / 自动化接入更安全，但旧脚本可能需要复核 |
另外还有一项独立工作：改进 HTML 处理（Improved HTML processing），属于输入与输出层面的加固，通常与 XSS 类风险相关。
我们的判断是：这三项会直接影响「用脚本管站」的人。如果你用 REST API 或应用密码做自动发布、备份、同步，7.2 发布前应把凭据与权限单独核一遍。可参考WordPress REST API 进阶实战里关于鉴权的部分，以及WordPress 安全加固清单。
样式与区块：从「能改」走向「改得准」
7.2 在设计侧的目标很明确——让样式结果更可预测。具体落在四件事上：
- 表单元素进全局样式：以往表单控件的样式常被主题硬编码，7.2 后可在 Global Styles 里统一调，主题不用再靠大量覆盖式 CSS 。
- 响应式样式扩展到第三方区块：自定义区块也能带上自己的控件参与响应式设置，不再只有核心区块享受这套能力。
- 自定义状态（custom states）：可以为区块定义 hover 、 active 等状态样式，并支持查看「继承来的样式」，减少「为什么这里变了」的困惑。
- 新增两个内容区块：Description List 补上语义化定义列表的空缺，Table of Contents 则让长文目录不再依赖插件。
对主题作者而言，「目录区块原生化」是个信号：能被引擎和 AI 稳定解析的结构化内容，正在被官方收编进核心。如果你在做主题或长文模板，现在就该考虑目录、描述列表这类语义元素的默认样式覆盖。区块与全局样式的基础可参考区块主题入门：theme.json 与站点编辑器。
可扩展站点编辑器：插件作者的分水岭
7.2 的站点编辑器正在换一套可扩展底座（基于 wordpress/boot 路由包），并已接近与现有编辑器功能对齐。它的关键变化是：通过服务端 view-config 端点，插件作者可以注册自己的界面与设置，而不必再各写一套一次性 API 。
配套还有两项：DataViews / DataForms 让第三方可以控制「哪些字段出现、哪些布局可用」；导航编辑也在向站点编辑器侧边栏迁移。这意味着后台列表、表单类界面未来会越来越统一，插件里自绘的表格与设置页将逐步显得割裂。
AI 相关：先进插件，不进核心
官方重申了 7.1 周期定下的原则：AI 功能必须先证明有真实采用率和实用价值，才会被考虑进核心。因此 7.2 的 AI 工作全部在 AI 插件中推进，不保证落地，包括：
- 更多 WordPress abilities（能力），探索写入类能力，并把只读覆盖扩展到媒体、分类法、评论；
- 把 MCP Adapter 更新到最新 MCP 规范，同时让能力定义与协议版本解耦；
- 在 WordPress.org 插件目录发布标准 MCP Adapter，像普通插件一样安装更新；
- 探索 WebMCP（浏览器内智能体工作流）、智能体身份与委托、向量检索与语义搜索、 PHP AI Client 的流式响应。
想让这些能力早点进核心，官方给出的路径很直接：去用、去测 AI 插件并反馈。能力机制本身可先看WordPress Abilities API 是什么。
站点主现在可以做的 4 件事
- 盘点自动化凭据。把所有使用应用密码、 REST 、第三方 API Key 的脚本列一份清单，标注权限范围与最后使用时间，废弃的立即吊销。
- 在预发布环境跑一遍 7.2 测试版。重点是表单样式、自定义区块的响应式控件、以及后台列表类界面，确认自定义设置页没有冲突。
- 检查主题对语义元素的支持。确认主题对 dl / dt / dd 与目录类结构有基本排版，避免原生目录区块上线后样式塌陷。
- 把升级流程固定成清单。备份、切维护页、升级、回归检查、恢复流量，按WordPress 安全更新怎么操作不崩里的顺序执行，别在正式环境直接点升级。
常见问题
WordPress 7.2 什么时候发布？
sudo 模式会不会让后台操作变麻烦？
Secrets API 出来后，老的插件密钥会失效吗？
目录区块进核心后，还需要目录插件吗？
默认主题 Ipsum 适合直接用吗？
顺带一提：本站版式短代码怎么写
本文用到的提示条、折叠块、步骤块都由主题短代码提供，写法示例（方括号用实体编码表示，避免被当成真实短代码执行）：[jinyu_tip type="info"]内容[/jinyu_tip]。
展开查看常用短代码写法
[jinyu_tip type="info"]…[/jinyu_tip]：提示条，type 可选 info / warning / danger 。[jinyu_collapse title="标题"]…[/jinyu_collapse]：折叠长内容。[jinyu_btn type="primary" href="链接"]按钮文字[/jinyu_btn]：行动按钮。[jinyu_howto title="标题"][jinyu_step]步骤[/jinyu_step][/jinyu_howto]：操作步骤。[jinyu_faq][jinyu_faq_item q="问题"]答案[/jinyu_faq_item][/jinyu_faq]：FAQ 区块。
来源：WordPress.org 核心团队博客《 Roadmap to 7.2 》（2026-09-18，make.wordpress.org/core）。本文为中文原创改写，观点、对比表与准备清单为本站基于官方素材的独立整理；路线图内容存在变更可能，最终以 WordPress.org 官方发布公告为准。
评论 (0)