WP Notify meeting for this week cancelled.

Due to circumstances out of my control, I was unable to post the agenda last week and I’m unable to run the early WP Notify meeting this week.

We will therefore skip this week’s meeting and pick things up next week.

Apologies to anyone for the inconvenience.


WP Notify Meeting Recap – September 2, 2019

This post summarises the weekly WP Notify chat meeting from September 2nd 2019 (agenda / Slack Archive).

Weekly WP Notify meetings are held every Monday at 14:00 UTC and 22:00 UTC respectively.

Requirements gathering tools

Based on the discussions from last weeks meetings, and the comments on the recap post, the general consensus is that a combination of a single Google document and the Make blogs and/or trac tickets would be suitable enough for our requirements gathering efforts. @nadir is of the opinion that trac is not suited for this, it gets noisy quickly with any reference or simple change, it will also add mental space to anyone triaging.

Project Naming

@netweb raised a good point and enquired as to whether there was any specific reason for naming the project “WP-Notify”, and suggested “Notifications-API”. However, as the project aims to introduce a better overall experience, of which a new API will form part of, other names suggested include:

  • Notifications Feature
  • Notifications System
  • Notifications Hub
  • WP Notifications

@netweb added his feedback on the various names during the second meeting, and is still in favour of “Notifications API”, based on the fact that this was what the original proposal was called, and will the vast majority of the work required to be undertaken.

Requirements gathering process

We need to put together a team who will work on this document, so if you’re keen to assist with compiling this document, based on the original trac ticket and the project proposal, please comment on this post of this meeting. We probably need 2 – 3 extra hands, over and above @psykro

Open floor

  • @hrmervin will be, sometime in the next few weeks, compiling a team members list – with time zones, and desired area to contribute to.
  • @folletto pointed out that we should reach out at some point to existing businesses and plugin developers to make sure they can extend the system as they need.
  • A11y considerations where discussed and @hrmervin has offered to take lead on such efforts.

Comments/suggestions are encouraged and welcome.

#feature-notifications, #summary

WP Notify weekly meeting agenda for 2 September 2019

Here is the agenda for the weekly meeting happening today, Monday, September 2, 2019, 14:00 UTC and Monday, September 2, 2019, 22:00 UTC. Please share any items you’d like to include in the comments below!

  • Opening and welcome
  • Decision on requirements gathering tools
  • Project naming
  • Requirements gathering planning
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #feature-notifications channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-notifications

WP Notify Meeting Recap – August 26, 2019

The following is a summary of the kick off  WP Notify meetings that occurred on Monday, August 26, 2019. Weekly WP Notify are held every Monday at 14:00 UTC and 22:00 UTC respectively. A full transcript can be found here in the #feature-notifications channel in the Make WordPress Slack.

Attendees: @jon_bossenger, @juhise, @Hareesh, @nik, @richard_korthuis, @netpassprodsr, @jpry, @felipeelia, @sergey, @patpgogy, @timothybjacobs @hrmervin, @mnelson4, @justinahinon, @sergey, @garrett-eclipse, @xendin.unknown, @mikeschinkel


We kicked of both meetings with a review of the current project status, with a focus on the original trac ticket and the proposal post.

Next steps

  • Our proposed next step is to review the current data and start collecting all of the requirements.
  • This should also include any design requirements, and a data model that needs to be able to handle all of the use cases
  • Our ultimate first goal for the next few weeks or so would be a requirements document, including designs, and the data model

Requirements gathering tools

An important part of this process would be to agree on the tools we will use to gather and document the project requirements. Some form of collaborative documentation tool that doesn’t limit anyone based on operating system or location seems like the best choice. Options discussed include:

  • Google Docs
  • Microsoft offers a onedrive.live complement to Google Docs
  • A GitHub/GitLab repo, with PR’s working as ways to accept items for the document
  • @netpassprodsr was curious as to whether Slack’s document store be a practical option?
  • @hrmervin pointed out the using GitHub/GitLab might be limiting to non developer folks

There was also a lively discussion around the actual technical implementation, however it was agreed that it is too early to be discussing this.

Comments/suggestions are encouraged and welcome.

#feature-notifications, #summary

WP Notify Kick off meeting agenda for August 26th 2019

Here is the agenda for the kick off meeting happening next week, Monday, August 26, 2019, 14:00 UTC and Monday, August 26, 2019, 22:00 UTC. Please share any items you’d like to include in the comments below!

  • Opening and welcome
  • Review of current project status
  • Discussion of next steps
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #feature-notifications channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-notifications

WP Notify Kick off meeting announcement

I’d like to announce the first meeting of the WP Notify project. The meeting will be held on Monday 26 August 2019 in the #feature-notifications channel.

In order to allow for multiple time zones, we’ll be having two meetings, one at 14:00 UTC, run by myself, and one at 22:00 UTC, run by @hrmervin. We’ll do our best to keep these two meeting times going forward.

I will post an agenda for the meeting closer to the time, and to allow folks to propose agenda items for the meeting.


Feature Project Proposal: WP Notify

This detailed proposal was originally drafted by @schlessera, who unfortunately does not have the resources to commit to executing the project. I am however thankful that he has agreed to assist, in an advisory role.


WordPress is currently lacking a fundamental mechanism: sending notifications to users to give them feedback about state changes in the system. Traditionally, plugin developers and Core have been using admin notices for this purpose, but this solution is lackluster at best and comes with a lot of disadvantages:

  • They are rendered into the normal working area in the dashboard and can even push the actual page content below the fold.
  • The user has no control over how or when they want to deal with them, therefore they see them in a mostly negative fashion.
  • They are nothing more than printed HTML. Because they lack any kind of structure, it is not possible to manipulate them in an automated fashion.
  • Their persistence is not regulated, which leads to many different implementations as well as cruft in the database.

For the above reasons, there’s a general consensus that admin notice are not up to the task and need a more robust replacement that can deal with current and future notification needs.

I hereby want to officially kickstart a Feature Project called “WP Notify“.

Project Scope

The initial project will cover an extensible backend implementation as well as a single frontend use case.

A. Backend implementation

The backend implementation will cover the following elements:

  • An object model that is extensible as well as serializable (to JSON).
  • A persistence abstraction that comes with an initial WPDB implementation.
  • A background queue that processes notifications to distribute them across channels, for use cases where this is a costly operation, like sending them through email.
  • A simplified procedural API that allows for easy manipulations the way plugin developers are accustomed to.
  • REST API controllers that provide endpoints to manage the notification from the frontend.

B. Frontend use case

The frontend use case will cover the following elements:

  • An admin bar integration that shows notification state and opens a panel to read and dismiss current notifications.
  • An settings page that lets the user control which notifications to show/hide in the admin bar and which notifications to forward through email.

Technical Requirements

  • Objects must be serializable to JSON in such a way that it can be sent to the client, either as a localized JavaScript snippet or as a REST API response.
  • A notification can have one or more recipients, which can be users, roles or a mixture of both.
  • A recipient can configure the channel(s) they want to receive the notifications in, on a “per-group” basis.
  • Distribution across channels is not directly coupled to the frontend request, but works as a background queue.
  • The admin bar integration needs to build on top of the work done with Gutenberg and use a reactive interface powered by the REST API.

Some Clarifications

Did this just come out of the blue?

No, the need for a notification subsystem has been identified a long time ago. Current discussions have been centralized in the Trac ticket #43484.

Why does this document talk about a “single frontend use case”? Does the proposal not already cover everything anyway?

No, having a sort of “admin bar hub” to manage your notifications is indeed only one potential use of the the notifications subsystem. The way it is currently planned, it could easily have other use cases, like the following examples:

  • Forwarding notifications to a webhook, for integrations into third-party services like Slack
  • Providing a webhook to feed notifications from third-party services like GitHub into WordPress
  • Showing notifications in a management system like cPanel or ManageWP
  • Integrating notifications contextually into other parts of the admin experience in a targeted way
  • Providing a “feed” view/endpoint
  • Letting other servers or tools send notifications to WordPress users/roles over the REST API, like a cron job completing a shell maintenance task
  • Attaching server notification systems like notify-send or growl to your WordPress dashboard

Why have so many complex moving pieces? Isn’t this called over-engineering?

Complex solutions can easily be adapted to fit simpler needs, while the opposite is not true. As you can see with the current admin notices, a simplistic solution that tries to solve a complex problem causes more harm than good, as you cannot just get rid of inherent complexity. On the contrary, a solution that is not properly adapted will cause additional complexity just because of the amount of side-effects it will generate.

I am certain that building a notifications mechanism for an entire platform like WordPress that fits the entire spectrum of scenarios from simple blogs to enterprise-grade custom solutions is inherently complex. An abstraction allows us to put the main extensibility points in place to stay future-proof and then concentrate on the few basic implementations we need for 80% use cases… without having locked out developers with more exotic needs and while at the same time leaving the solution open to creative improvements in the future.

What is this “simplified procedural API” all about?

While building an extensible object model will allow us to extend the implementations in a safe way in the future, it also comes with more complex usage when interacted with directly.

That is why we should include a simplified procedural wrapper around the object model that mimics the way plugin & theme developers are used to work with WordPress.

As an example, instead of creating an instance of a factory first, to then retrieve a base notification with a simple message and a single recipient to it, we could have a simplified wrapper that looks like this:

// Create a new notification for the current user.
wp_notify( 'MyBackupPlugin', get_current_user_id(), 'Backup completed!' );

// Mark a specific notification as read.
get_notification( $notification_id )->mark_as_read();

These procedural functions come with a default setup that can be controlled via actions & filters.

Such a simplified layer allows us to have the best of both worlds: robust and extensible behind the scenes, and simple and intuitive facing the user.

So we’re building a complex object model and then wrap it with simplified functions. This is not how WordPress code is usually done…

Indeed. Given that this project is mostly isolated and can be approached in an unencumbered way, it offers the perfect opportunity to improve the general way WordPress Core code is done. It should demonstrate that it is possible to get the combined benefits of both an extensible object model that is robust to work with as well as an intuitive public-facing API that provides a low barrier of entry.

There is a lot of momentum right now on the WordPress Core developer front. But general coding conventions are still based in large parts on what we inherited from the project’s roots. This project can help define a new set of WordPress-specific coding patterns that are not tied to the compromised patterns we inherited from the PHP 4 era.

Yes, this is not how WordPress code is usually done … yet! But we can change that!

Wasn’t there a similar Feature Project already?

You’re referring to the post by John Blackbourn that he wrote in 2016. That project proposal never really got off the ground, and I got confirmation from John that it is abandoned and should hopefully be replaced, as the need for it is still there.

Call for Volunteers

If the above sounds like something you would like to contribute to, please either write a brief comment below this post, with the area you are interested in and the skills you can offer.

Alternatively, you can join the discussions on Slack in the #feature-notifications channel or on Trac ticket #43484.

This project covers a lot of different areas, like advanced backend code, scalable database gymnastics, reactive JavaScript code and dynamic UI/UX design.

All help is welcome, but please be aware that different topics will be in focus at different stages of the project.

Next Steps

There have already been a number of interested parties on the Trac ticket or in the #feature-notifications channel and I look forward to your feedback, comments and suggestions. By the 19th of August I plan to have an initial project kick off meeting scheduled, so that we can set up a plan of how best to move forward.

Dev Chat Summary: October 5 (4.7 week 7)

This post summarizes the dev chat meeting from October 5th (agenda, Slack archive).


Components & Features

  • Non-4.7 Feature Proposal: Notifications API (@johnbillion)
    • Discussion on this in #feature-notifications, but no meeting scheduled
  • Non-4.7 Feature Proposal: Status API for taxonomy terms (@boonebgorges)
  • Customize (@westonruter, @celloexpressions)
    • Feature proposal for 4.7: Discovering and installing themes in the customizer (@celloexpressions)
      • Deadline for feedback and review from various teams is Wednesday, October 12th
      • Need review/audit from Flow (and mobile), Docs, Security, Polyglots/i18n, Design/UX, Accessibility, and when those are done a Code Review (@westonruter)
      • Would like user testing & testing of the patch itself
      • Please provide feedback as a comment on the Feature Proposal Post, User Testing Post, or via Trac
      • The plan is to begin final code review/commit next Wednesday, October 12th, so feedback needs to be received by then
    • Merge proposal for Customize Changesets (fka Transactions) – Trac & Github
      • Needs developer attention, specifically on expected/best behavior on maintaining changesets across multiple theme previewing/testing. Details to be included in a Make/Core post by @westonruter with discussion continuing in #core-customize
    • Otherwise we’re working toward finalizing patches for all of our other projects and will publish a feature proposal for custom CSS in the next week. All 4.7 customize non-bugs have an owner assigned to work toward commit or punt to a future release.
  • Twenty Seventeen (@davidakennedy, @melchoyce)
    • Highlight: start testing the theme, we need help on the features from a development perspective, plan is theme merging into core by October 19th with enhancements needing to complete by October 26th
    • Latest theme update
    • Latest features update
    • Theme recap: This week the initial design implementation was merged into the master branch on GitHub. The rest of the theme is moving along nicely, and the initial design implementation should make it easier to test the theme’s features. Please start testing, and creating issues! The next step is to get a public demo up to help with that. Best way to test is to get it via GitHub ( if using wp-cli, wp theme install <github-url> --activate).
    • Features recap: For the multi-panel feature, at the weekly meeting, the feature was reduced in scope to focus only on the front page of sites, only include content from pages and be implemented in the Customizer. @karmatosed has some mocks posted (including live preview). For the video headers feature, it still needs to be focused with a reasonable MVP defined. Although, some recent feedback on the ticket is helping there.
    • Twenty Seventeen needs you. Home pages should be fun to create and a heck of alot easier. Headers can be even more captivating. If you’re interested in working on either of these projects, please let @davidakennedy know.
  • REST API (@krogsgard, @kadamwhite)
    • Settings (PR against the main plugin repo) and Meta (PR here against the meta repo) are still open for review from the team; we’ll be formally posting updates on Make/Core outlining the new functionality as these land
    • Need a lot of eyes on Authentication, released v2 beta 14 last weekend and intend to release a beta 15 with the merge-candidate functionality. Plan to propose that OAuth1 be included in the merge.
    • Testing and review is top priority right now. Docs for folks getting up and running with the API will be getting a strong push post-Proposal.
    • Next meeting: Thursday at 2pm UTC
  • Media (@mikeschroder, @joemcgill)
    • Latest update
    • Media search doesn’t include file name (#22744): Just committed a fix for a bug that was trampling existing JOINs. Please test, especially if you’re doing any custom filtering to media queries that might be impacted.
    • Starting work on potential feature plugin to introduce additional UX improvements to the media library. Likely future release material, but expect to fix some bugs and lay groundwork during this release. Development will happen in GitHub. Plan to make a feature project proposal after we’ve had some initial conversations about UI/UX direction.
    • After some conversation with @sheri, may still try to land a core media widget (#32417). Most of the work here has already been done, but need to make some decisions. We’ll plan to talk about this during our meeting on Friday at 5pm UTC in #core-images.
  • i18n (@swissspidy)
    • User Admin Language (#29783) landed this week. It allows each user to set their language (locale) and the admin will be translated accordingly for them. A dev note has yet to be written.
    • Focusing on making use of that feature by sending emails in the respective user’s locale. See #26511 if anyone wants to help with a new patch.
    • Introduce some JavaScript i18n functions (#20491): progress currently happens outside of core. There’s a proof of concept for extracting strings from JavaScript files as well as a PR on the GlotPress repository to add JSON export functionality.
  • Editor (@azaozz, @iseulde)
    • We’ll work on a better experiences for when nonces expire; posted an idea dump in #core-editor, thoughts on any points are very welcome.
    • Bug scrub Thursday at 4pm UTC in #core-editor.
    • In order to move ahead with several UI proposals/tickets we will need to get more usage data.
    • Planning to update TinyMCE next week, even if no new version by then.

#4-7, #dev-chat, #summary