WordPress 期待已久的功能通知项目有了设计方案，思路借鉴自 WordPress.com
WordPress 核心「功能通知（Feature Notifications）」项目重启后推进迅速。上周公布的提案显示，核心与插件的各类提醒将被统一收进一个全新的通知中心，用户通过管理栏顶部的铃铛图标进入。
提案由 Automattic 高级产品设计师 Poli Gilad 撰写，她的设计灵感直接来自 WordPress.com 自身的通知系统。方案公布三周前，Automattic 开发者布道师 Jonathan Bossenger 宣布结束三年间歇、重新接手该项目，并计划在 12 月 1 日以功能插件的形式发布 0.3.0 版本。
要解决的核心问题：插件提醒把后台页面挤垮了
Gilad 在提案中直言，WordPress 缺少一种能告诉用户「站点正在发生什么」的好机制。插件普遍退回到用 admin notices 推送消息，把页面整体往下顶，结果真正要紧的事情——比如支付失败、安全更新，或者同事抛来的一个疑问——全都淹没在各种促销和提醒之间。
「现有管理通知系统」早就是 WordPress 用户的痛点来源，不少人专门在社交媒体上晒出自家后台被各种通知塞满的惨状。Justin Tadlock 早在 2021 年为 WP Tavern 撰文时，就把这套机制形容为「WordPress 管理后台的狂野西部：没有规则，也没有次序」。
Bossenger 在 2019 年接手该项目（当时名为 WP Notify）时，也曾在 WP Tavern 的 Jukebox 播客中描述过类似场景：他登录客户站点后，得先读完半页、有时整整一页的通知，才能开始处理后台工作，而这些内容不过是插件更新、付费升级和主题促销之类的信息。
提案的核心设计：由核心统一接管通知样式
在 Gilad 的方案里，通知的呈现方式不再由各个插件自行决定，而是交给 WordPress 核心统一控制。
插件目前依赖 admin_notices 钩子，在各管理页面顶部自行打印消息；新设计则要求插件把通知详情发送给 WordPress，由插件从四种布局中挑选一种，核心则统一规定通知的标签方式与排序规则。每条通知都会显示：它讲了什么、来自谁，以及一个明确的下一步操作。
分级处理上，Gilad 的思路是：关键通知（例如支付争议）会固定在通知中心顶部，并在未被「解决」而不仅仅是「已读」之前，把铃铛的计数标红；警告类信息则归入一个新的「Alerts」标签页。
她的前后对比图直观呈现了差异：改造前后台被大量样式各异的 admin notices 淹没，改造后同样的内容在通知中心里呈现出统一的外观与观感。
Gilad 认为，WordPress.com 的通知系统已经在「每天数以百万计的用户」身上经过验证和打磨；她本人也在用 WooCommerce 和 WooPayments 的真实消息对原型进行测试，Jetpack 的通知排在下一轮测试清单上。
兼容性与后续争议
针对生态兼容性，Gilad 强调这套系统不会引入任何破坏性变更：「admin notices，包括自定义的那些，仍然可以继续工作。它们只是不再是 WordPress 通知未来要走的路。」 使用该通知系统的插件，「能一致地把消息传达出去，而不必靠一条条越来越大的通知把页面往下顶」——因为系统自带设计方向和一整套规则，谁发出来的通知看起来和表现得都一样。
提案中也留有若干待反馈的开放问题，包括：
- 三档严重级别（关键、警告、提示）是否够用，以及谁有权把一条通知判定为「关键」；
- 各类事件该通过什么渠道触达用户——铃铛、管理菜单里的计数、邮件，还是推送到站主手机——目标是「每条都只出现一次，且出现在正确的位置」；
- 每种通知是各自拥有独立徽章，还是共用少数几个通用徽章；「未读」是独立标签页还是过滤条件；
- 随着接入插件增多，通知设置如何保持可管理；
- 键盘导航与屏幕阅读器等辅助技术的兼容体验。
设计发布后的反馈整体偏正面，Woo 设计团队也在社交平台转发了原型的视频演示。WooCommerce Core 产品经理 James Kemp 称这是「WordPress 里早就该有的东西」，并提到从 2009 年开始使用 WordPress 时，通知中心这个话题就已经被反复讨论。
主要分歧：插件真的会用吗
争议的核心在于插件是否真的会迁移过来。既然现有 admin notices 继续可用，不少评论者追问：凭什么让插件作者改掉多年养成的习惯？
SYNTAX ERROR 的作者 Rune Rasmussen 质疑道：「那这样 spam 插件就可以继续刷后台了？如果是这样，我怀疑它们根本不会收手，这套系统顶多只能『帮到』那些负责任的插件作者……」 Gilad 回应表示，类似插件目录规范这类更严格的规则「可以在进入核心之后再补上，但目前并未确定」。她也在另一条评论中承认，让插件作者接受这套系统「会是最难的部分」。
PlugPress 创始人 Fahim Reza 则建议，插件不应允许把促销或升级优惠标记为关键级别。Gilad 回应称，在她设计中促销类通知「永远不可能是关键级别，排序也更靠后，并且每个插件的通知都可以用一个开关单独关掉」。
关闭后反复出现的通知，成为 0.3.0 的争议点
在关于 WordPress 通知功能（feature-notifications）的讨论中，几位评论者提出了一个具体问题：后台通知（admin notices）在被关闭之后，仍然会再次出现。
Gilad 的回应是，插件当前的 0.3.0 版本已经内置了一个「忽略 / 关闭」按钮；但她同时提出，如果通知本身只发送一次，并且按用户分别保存，那么这个按钮可能就不必要了。有评论者明确表示自己更希望保留这个按钮。Gilad 表示，这仍是一个悬而未决的开放问题。
按用户存储通知的改动已经合入
Bossenger 每周更新的最新一期说明（发布于周日）显示，该项目已经合并了一项改动，用于为每个用户分别存储通知记录。
这意味着通知不再是一份全局共享的列表，而是变成按人区分的状态——关闭某条通知的操作可以针对单个用户留存。
进入核心之后，还要看各插件自己的节奏
至于 Gilad 的设计何时能够真正进入 WordPress 核心，她的说法很直接：在她的文章里写的是「Not soon, and that's fine.」（不会很快，这也没关系）。
她补充说明了大致顺序：先有 0.3.0 版本，之后才谈核心合并；至于插件何时切换过去，则「由每个插件自行决定，按自己的节奏来」（up to each plugin, at its own pace）。
这意味着短期内，插件作者在是否迁移、什么时候迁移这件事上仍有完全的自主权，核心侧也不会给出强制时间表。
反馈渠道
目前三个反馈入口同时开放：
- Gilad 的文章评论区
- GitHub issue #655
- WordPress Slack 的 #feature-notifications 频道
落地建议
对插件作者而言，核心信号已经很明确：核心提供了通知的排版规则与统一入口，接入能换来一致、可控、不再破坏页面布局的呈现，且不存在破坏性变更——提前适配不会带来迁移风险。
对站点运营者而言，可以关注 12 月 1 日 0.3.0 功能插件的发布节奏，早期试用能提前熟悉通知中心的分类与设置逻辑，也便于在推广类通知继续刷屏时手动关掉不想要的来源。
