[wp-trac] [WordPress Trac] #43484: WordPress Notification Center proposal

[WordPress Trac]

#43484: WordPress Notification Center proposal
-------------------------------------+-------------------------------------
 Reporter:  hedgefield               |       Owner:
     Type:  feature request          |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Mail                     |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  ux-feedback dev-         |     Focuses:  ui, accessibility,
  feedback                           |  administration
-------------------------------------+-------------------------------------
Changes (by netweb):

 * keywords:  ux-feedback => ux-feedback dev-feedback
 * component:  Users => Mail


Comment:

 Via https://make.wordpress.org/core/2016/10/03/feature-project-proposal-
 notifications-api/

 > [https://profiles.wordpress.org/johnbillion John Blackbourn] writes:
 >
 > '''Feature Project Proposal: Notifications API'''
 >
 > Most of the situations where WordPress sends an outgoing email can be
 classified as a notification. X just happened on your website and you
 should be aware of it.
 >
 > Back when WordPress was a youngster, the only way to reliably notify a
 user was via email. In 2016 we have many more options, including push
 notifications to mobile platforms, desktop notifications to browsers,
 messages to chat apps, endless services via webhooks, SMS messages, or
 even notifications in the WordPress admin area. The list goes on. For many
 users, email is no longer the optimal delivery mechanism for ephemeral
 notifications.
 >
 > To that end, let’s think about replacing `wp_mail()` with a modern API
 that allows developers to route notifications to services other than
 email, allow them to better modify notifications and the way in which
 they’re formatted, and allow them to do so without stepping on each
 others’ toes.
 >
 > The current lack of a notifications API (or even an email sending API)
 can be easily summed up:
 >
 > >''Problem: Plugin A wants to provide HTML emails, and Plugin B wants to
 send emails via an email delivery service such as Mandrill. Plugin C wants
 to disregard emails and send Slack notifications. It’s very difficult for
 these to co-exist.''
 >
 > '''Notification Destinations'''
 >
 > There are only two types of destination for a notification in WordPress.
 Most notifications are actually notifications to a user account that get
 delivered via email because it’s the only contact information available
 for every user account. The remaining notifications are explicitly
 notifications to an email address rather than a user account (or not yet
 attached to a user account), such as when a user signs up for a blog and
 needs to click a confirmation link before their user account gets created.
 >
 > With this in mind, you might be able to imagine a notification class in
 WordPress core that defaults to delivering notifications via email, but
 which can be extended by a plugin on a per-user and per-notification basis
 to deliver notifications via any of the means listed above. WordPress core
 would support delivery via email and provide the API that allows plugins
 to implement delivery via other means.
 >
 > With a well-designed API, multiple plugins can co-exist in order to
 deliver different notifications via different mechanisms, format email
 notifications as HTML, easily disable notifications, change the delivery
 mechanism for email notifications, or provide a UI for users to manage
 their notification preferences and destinations.
 >
 > '''Planning a Notifications API'''
 >
 > I’d like to begin work on a feature project with the intent of designing
 and implementing such an API. I’d like to get input from authors of
 existing plugins that provide functionality such as delivering
 notifications via a service other than email, that override the default
 email delivery mechanism, or that implement extra notifications (such as
 e-commerce sale notifications), in order that the API can be backwards
 compatible and that we can get some plugin implementations built during
 the API’s development.
 >
 > I already have some technical ideas regarding how the API might look,
 but I’m conscious that such an API needs to be well-designed before anyone
 jumps into writing code. Maybe we can even try some test-driven
 development? Who knows.
 >
 > In addition, consultation and involvement with the team that are working
 on [https://make.wordpress.org/core/tag/two-factor/ the two-factor
 authentication feature project] is important as it implements several
 delivery mechanisms for 2FA codes that could potentially be made simpler
 with a notifications API.

 Note: ''There [https://make.wordpress.org/core/2016/10/03/feature-project-
 proposal-notifications-api/#comment-31197 are comments] from the above
 post discussing the proposal further, what's relevant and related should
 also be bought into the discussion here on this ticket''

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43484#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform