WordPress 7.1 计划在 8 月 19 日随 WordCamp US 一同发布，其中一项为三大核心数据类型引入只读权限的提案正面临激烈争议。
提案内容：三项基础只读权限
Automattic 赞助的核心提交者 Jorge Costa 于上周在 Make WordPress Core 博客发布了这份合并提案，主张在 WordPress 7.1 中新增 core/read-settings、core/read-content、core/read-users 三个只读权限。
Abilities API 是 WordPress 6.9 引入的注册机制，为系统提供了一种结构化、机器可读的方式来描述站点能力。该 API 在 7.0 扩展至浏览器端，旨在让 AI Agent、自动化工具和插件能够通过统一接口发现并调用功能，而无需在分散的函数和端点中自行拼凑。
Costa 在提案中指出，没有核心只读权限，这些集成工具即便调用了模型，也无法可靠地回答"存在哪些文章"或"哪个页面是首页"等基础问题。
三组权限均为只读，其中设置项和文章类型需通过新增的 showinabilities 标志主动声明可见性，逻辑与 REST API 的 showinrest 类似。Costa 认为，这三项权限理应进入核心代码，因为当前生态已在各自实现"获取文章"这类基础操作，一套共享标准能为权限审查、数据结构设计和边界情况处理提供统一入口。
维护者质疑：测试不足、命名存疑
然而，rtCamp 高级工程师 David Levine——AI 团队成员、Abilities API 组件维护者——明确表达了"强烈反对"。
Levine 在评论中写道，三项权限中仅有 core/read-settings 一项曾合并至 WordPress AI 插件，且那次合并"明确基于"该权限将在插件内经历充分 review 和迭代这一前提，其余两项权限"仍处于待定状态"。
他同时对命名规范提出异议：提案中的 read- 前缀与 Abilities API 6.9 版本确立的 get- 模式相冲突。此外，Levine 还质疑 API 数据结构与 REST API 过于相似：
“WordPress 已有核心 REST API，且核心代码理应向后兼容。核心权限需要成为功能原语，能同时满足 REST、CLI、命令面板等多种场景的共同需求。这些数据结构不仅未经测试，也缺乏对现有提案形态在不同消费场景下的探索。”
Levine 还提及，AI 团队 6 月 24 日的会议已达成共识——这三项权限应至少在 AI 插件中完整经历一个发布周期后再考虑纳入核心。他同时对 7.1 发布前其他维护者（如 Automattic 的 Greg Ziółkowski）的参与度表示担忧。
双方观点碰撞
Automattic 赞助的贡献者、7.1 版本负责人 Anne McCarthy 对 Levine 的说法提出反驳，认为一次贡献者电话会议不构成正式决策，"尤其是在负责该功能的团队、发布小组及更广泛的核心提交者均未出席的情况下"。她表示，合并提案本身就是为此类讨论而设。
Levine 则援引自动生成的会议记录回应，指出该决策反映的是权限的就绪状态以及 Beta 1 前团队的实际承载能力。
Costa 在评论中反驳称，相关工作并非从零开始：其中一项权限曾进入核心 trunk，而内容权限则基于今年 2 月的早期工作。针对命名问题，他解释 read 前缀源自一次 review 讨论，目的是帮助大语言模型更好地理解权限名称的含义，并表示若存在充分理由支持 get，他愿意接受调整。
Costa 强调，设置、用户和文章已是 WordPress 最基础的数据类型，等到 7.2 再推进可能面临同样的质疑。"我最想确认的是，在 Beta 发布前，这些现有权限中是否存在我们来不及修复的具体问题。"
关键时间节点
- Beta 1：2026 年 7 月 15 日
- 正式版：2026 年 8 月 19 日（WordCamp US 同期）
