A new design exploration for Feature Notifications proposes a centralized notification panel accessible through a bell icon across the WordPress admin, block editor, and front end of a site. The system is intended to bring notifications from Core and plugins into one place, providing a shared alternative to the different ways individual plugins currently display messages, including admin notices, banners, and inbox cards.
The latest prototype, tested against notifications from WooCommerce and WooPayments, introduces four notification layouts and a shared set of rules for how messages are displayed, prioritized, and managed
How the proposed notification system would work
Feature Notifications (launched as WP Notify in 2019) is the project exploring a unified notifications system for WordPress. Poli Gilad’s proposal builds on the need for a consistent way to communicate activity across WordPress.
Currently, plugins use different formats, including admin notices, inbox cards, banners, and badges, without a shared set of rules for determining which messages deserve attention. As Gilad explains, “There’s no shared sense of what’s important, so the important things get lost among the rest.”
The design takes inspiration from the WordPress.com notifications panel by Ollie Rozdarz and the WordPress.com notifications team, which Gilad describes as “tested and refined with millions of people every day.” Gilad also provided a seven-minute walkthrough video, and a live demo.
Feature Notifications had been quiet since version 0.2.0 was released in April 2023. In a recent update, Jonathan Bossenger outlined plans for version 0.3.0, which he described as the project’s first functional MVP. The release is planned as a feature plugin, with a target date of December 1.
The latest design is the second version of the prototype. While the first demonstrated the general concept, the newer version focuses on defining how notifications should be structured and how plugins would use the system.
Gilad explains that “Plugins send data, not layout.” Under the proposed approach, plugins would select from four predefined layouts: Standard, Object, Conversation, and Group.
The prototype also introduces five separate dimensions that determine how notifications are categorized and displayed: type, severity, intent, read state, and sender status. Gilad uses a payment dispute to demonstrate how these dimensions work. It would be categorized as a payment notification, marked critical in severity, assigned an operational intent, and identified as unread. Its sender status could initially show “Needs response” and later change to “Won”.
Severity would determine which notifications receive priority. Critical notifications would remain pinned at the top of the panel until resolved, rather than disappearing once read. The notification count on the bell would also turn red while a critical item remains unresolved. A separate Alerts tab would collect critical notifications and warnings. Gilad explains that “Critical is rare and visible. It stays on top and turns the bell’s count red until it’s resolved, not just read.”
The proposal also includes measures to reduce repeated and unnecessary notifications. Repeated messages would replace earlier ones, multiple notifications of the same kind could be grouped together, and users would be able to turn off tips and offers through a single setting.
Several aspects of the design remain open for feedback. These include whether each notification type should have its own badge or use a smaller set of generic badges, whether three severity levels are sufficient, and whether information about the person who performed an action and the item involved should become standardized fields. Other questions concern how events should be distributed across notification channels, including email and mobile push notifications, and how unread notifications and settings should be organized as more plugins adopt the system.
Accessibility is also under consideration. The prototype follows the keyboard navigation used by the WordPress.com notifications panel, and Gilad is seeking feedback on how the interaction works with screen readers and other assistive technologies.
Gilad plans to continue collecting feedback and testing the system with other plugins. WooCommerce was the first detailed test case, and Jetpack is next.
The complete system is not expected to ship with v 0.3.0, Gilad said ” 0.3.0 comes first, as a feature plugin, and merging into core follows after it.” Existing plugins will continue to work, and no APIs or hooks are being removed. Individual plugin developers will decide when to adopt the proposed notification system.
Community Response
Community members welcomed the proposal but raised concerns about whether it would prevent plugins from repeatedly displaying unwanted promotions and notices.
Adrian33000 said users should be able to dismiss notices permanently rather than having them reappear every time they open the dashboard, “Deletion needs to be permanent,”. The comment also prompted discussion about whether the new system should retain a dismiss button, with Adrian arguing that users should be able to remove unwanted notifications without going into settings.
Fahim Reza (PlugPress founder) raised concerns about promotional messages appearing in the notification panel, saying plugins should not be allowed to mark upgrade offers as critical. Reza also suggested adding snooze controls and exposing notifications through the WordPress Abilities API so AI agents and external tools could access them.
The concern about plugin spam also came from Rune Rasmussen, who questioned whether developers would still be able to flood the admin with notices under the proposed system. Michael Campanella raised a related concern about plugin developers continuing to use existing notices for advertisements and upsells.
Brian Coords noted that the teams handling notifications at Woo and WordPress.com are offering to help with the feature.