WP Notify Meeting Recap – February 24 2020

This is a recap of the WP Notify meeting held on Monday, February 24, 2020, 14:00 UTC. You can read the full meeting discussion here in Slack.

We focused on the next sections of the requirements document, Section 3 “Current Status”, and Section 4 “Project Goals”.

Section 3. Current Status

  • Finalized description of existing APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. features and limitations

Section 4. Project Goals

  • We continue refining the definitions of our MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia (minimum viable productMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia) a.k.a. Version 1.0
  • We outlined important research the project should include
  • We noted importance of retaining backwards compatibility of notifications handling

At the close of the meeting, @hrmervin posed the question of how/if GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ methods of notification handling can influence this project, either in short term or long term. 

Next SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. Meeting

Join us next week, where we’ll continue the discussion on the project goals, and system feature requirements. 

📅 Monday, March 2 @ 14:00 UTC

#admin, #feature-notifications, #notifications

WordPress 5.3: Site Admin Email Verification Screen

In WordPress 5.3, a new screen has been introduced to help ensure the site’s administration email remains accurate and up to date. The site’s adminadmin (and super admin) email (as defined when installing WordPress, and found on the Settings > General page) is a critical part of every WordPress site. This new screen will help site owners remain in full control of their site, even as years go by.

How does this work?

By default, administrators will see a screen after logging in that lists the site’s admin email address once every 6 months.

They are presented with 4 actions:

  1. The site’s email is verified as correct: After clicking “The email is correct” button, the user is taken to the Dashboard with an admin notice saying “Thank you for verifying”. The screen will be hidden for 6 months from all administrators.
  2. The site’s email needs to be changed: After clicking the “Update” button, the user is taken to the Settings > General page where they can update the site’s email address. Administrators will be presented with the verification screen the next time they log in.
  3. The user clicks “Remind me later”: the user is taken to the Dashboard. Administators will see the screen again after 3 days have passed.
  4. Back to “Site Name”: When this link is clicked, the user will be taken to the site’s home page. Administrators will be presented with the verification screen the next time they log in.

Available Actions and Filters


There are a few action hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. on the verification page that developers can use to customize the screen.

  • admin_email_confirm – Fires before the admin email confirm form.
  • admin_email_confirm_form – Fires inside the admin-email-confirm-form form tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), but before any other output.

A new action hook after the form was not introduced. Instead, use the login_footer action, which is called just after the closing </form> tag. The if ( 'confirm_admin_email' === $_GET['action'] ) conditional can be used to check that the email verification screen is being shown.


One new filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., admin_email_check_interval, has also been introduced. This filter can be used to change the frequency that administrators should see the verification screen.

The following example changes the interval from the default of 6 months to 2 months:

function myplugin_admin_email_check_interval( $interval ) {
	return 2 * MONTH_IN_SECONDS;
add_filter( 'admin_email_check_interval', 'myplugin_admin_email_check_interval' );

Note: The returned value should always be in seconds.

This filter can also be used to disable the feature by returning a “falsey” value, such as 0, or false.

The following example will disable the admin email verification check:

add_filter( 'admin_email_check_interval', '__return_false' );

For more information about these changes, check out #46349 in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Props to @desrosj for peer review.

#5-3, #admin, #dev-notes

The way the edit lock works now, if you …

The way the edit lock works now, if you close your browser with the post open, the lock will stay in effect until it times out. Might it not be better if we shortened the edit lock time to something like 120 seconds and kept it locked via an XHR every 90 seconds that the edit screen for that post is open?

#admin, #edit-lock, #question, #ux

Implementation of the new design for the …

Implementation of the new design for the Manage->Posts page is almost complete. Looking good.

#admin, #ui