Dev Chat Agenda for October 30, 2019 (5.3 week 11)

Here is the agenda for the weekly meeting happening later today: Wednesday 30 October 2019 at 20:00 UTC. Please share any items you’d like to include in the comments below!

  • Announcements
    • Highlighted posts
    • Move Dev chat meeting time (end of daylight saving time)
  • WCUS/contributor day
  • Upcoming Release Discussions
  • Calls from component maintainers
  • 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 #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-3, #agenda, #devchat

Dev Chat: 10/23/2019

The facilitator for this week’s chat was @audrasjb.

Announcements

WordPress version 5.3-RC2 was released on Tuesday. Everyone please help by testing out the RC.

The latest Dev Note published for 5.3 discuses “Noteworthy Admin CSS Changes in WordPress 5.3”.

Also, the official Field Guide for 5.3 was published!

@audrasjb called attention to the wonderful documentation work this cycle by @justinahinon and @jeffpaul. Thank you to both for their extraordinary efforts!

5.3 Updates

@azaozz Pointed out that there are only two tickets needing work after RC2, excluding the About Page. Follow the ticket progress in Trac here.

@ianbelanger informed the group that there are currently 0 tickets in the Bundled Themes component for Twenty Twenty. However, he added that an RC3 release would be helpful.

@audrasjb brought up ticket #48396 regarding @afercia‘s request to revert two lines of CSS to remove an unwanted changes on disabled buttons. @azaozz confirmed the revert to be a minor one and suggested that it move forward based on testing.

A pre-RC3 Bug Scrub in the #core channel was tentatively scheduled for Monday October 28, 2019 15:00 UTC. If there are no new tickets or regressions reported prior, the scrub will not take place.

@sergeybiryukov asked about branching for 5.3 this week. @peterwilsoncc suggested certainly branching before WordCamp US Contributor Day, as to allow for good-first-tickets to be committed for new contributors. @desrosj added that branching could be done at any time now that the dust has settled from RC2, but deferred to @azaozz‘s judgement as Core Tech Lead for 5.3. @azaozz suggested trying to resolve a couple of remaining issues in 5.3 prior to branching in the next few days, and a consensus was reached around this idea.

These notes were taking by @davidbaumwald and proofread by @audrasjb

#5-3, #dev-chat, #summary

Dev Chat Agenda for October 23, 2019 (5.3 week 10)

Here is the agenda for the weekly meeting happening later today: Wednesday, October 23, 2019, 20:00 UTC. Please share any items you’d like to include in the comments below!

  • Announcements and highlighted posts
  • Upcoming Release Discussions
  • Calls from component maintainers
  • 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 #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-3, #agenda, #devchat

Noteworthy Admin CSS changes in WordPress 5.3

WordPress 5.3 will introduce a number of CSS changes in WordPress admin. While the necessity to improve wp-admin accessibility was previously raised in several Trac tickets, Gutenberg’s recent interface improvements made it necessary to improve the whole interface as well.

Background: in April 2019, WP-Campus conducted an accessibility audit of the new editor interface, made by an independent contractor, Tenon LLC. This audit raised issues in the editor but also in the media modal, which uses wp-admin styles. Fixing these issues on Gutenberg and on the media modal but not in the whole wp-admin interface would have been very inconsistent.

Some tickets were milestoned to the 5.3 release cycle to start backporting Gutenberg accessibility improvements to the whole admin interface. These first tickets aim to improve:

  • Color contrasts on form fields and buttons
  • Focus styles on form fields and buttons
  • Content behavior on text zoom

Backporting some of Gutenberg’s styles to fix these issues introduced some visual issues with the interface elements hierarchy. Therefore, Design and Accessibility teams worked on the overall visual hierarchy:

  • darker tables and metaboxes borders were introduced for a better hierarchy between interface elements

Note for plugin authors and WordPress developers

These changes are only CSS changes, and not structural changes, so the HTML markup is exactly the same as before, with the same class attributes on each element.

In short, your styles should align with these changes if interface elements are not overridden by custom CSS. If you are overriding WordPress Admin CSS on form elements, you should test your plugins or your custom developments against WordPress 5.3 RC 1.

If you are a plugin author, there are different use cases:

  • Plugins that are using default Admin CSS styles should work just like before.
  • Plugins that are using custom Admin CSS styles by overriding default Admin CSS should be checked against 5.3.
  • Plugins that are using fully customized Admin CSS styles should not be concerned by those changes.

In general, plugin authors and WordPress developers are encouraged to:

  • remove any fixed heights: flexible heights are the WordPress recommended standard (and one of the main goals of the Admin CSS changes).
  • remove any custom top and bottom padding values.
  • remove any custom line-height values.
  • update their CSS code to override new focus/hover buttons colors if they use custom colors on this type of element.

In the next section of this dev note, you’ll find some noteworthy CSS changes coming in WordPress 5.3.

Main things that are changing in 5.3:

  • Forms fields: 
    • text inputs
    • textareas
    • selects
    • checkboxes
    • radiobuttons
    • both primary and secondary buttons
    • colorpickers
  • Tables, notifications and metaboxes

Known issues

Available for testing in WordPress 5.3 RC 1, these changes have been tested in various use cases and no breakage situation was identified during the tests. Please check the report for full information about the testing panel.

This is a work in progress, just like anything in WordPress Core. These usability improvements were implemented during summer 2019 then tested and iterated on September and October. After 5.3 is released, the idea is to iterate on wp-admin design to make it fully consistent with the editor interface, and to provide a great and accessible editorial experience for websites administrators. The next minor releases will fix small issues with 5.3 changes and the next majors will improve the consistency of user experiences between Gutenberg and WordPress administration.

Changes related to form fields

Text inputs

Legacy CSS code:

/* Legacy styles */
input[type=text] {
    border: 1px solid #ddd;
    box-shadow: inset 0 1px 2px rgba(0,0,0,.07);
    background-color: #fff;
    color: #32373c;
    outline: 0;
    transition: 50ms border-color ease-in-out;
}
input[type=text]:focus {
    border-color: #5b9dd9;
    box-shadow: 0 0 2px rgba(30,140,190,.8);
    outline: 2px solid transparent;
}
Legacy input style
Legacy focused input style

New CSS code:

/* New styles */
input[type=text] {
    padding: 0 8px;
    line-height: 2;
    min-height: 30px;
    box-shadow: 0 0 0 transparent;
    border-radius: 4px;
    border: 1px solid #7e8993;
    background-color: #fff;
    color: #32373c;
}
input[type=text]:focus {
    border-color: #007cba;
    box-shadow: 0 0 0 1px #007cba;
    outline: 2px solid transparent;
}
New input style
New focused input style

Textareas

Legacy CSS code:

/* Legacy styles */
textarea {
    border: 1px solid #ddd;
    box-shadow: inset 0 1px 2px rgba(0,0,0,.07);
    background-color: #fff;
    color: #32373c;
    outline: 0;
    transition: 50ms border-color ease-in-out;
}
textarea:focus {
    border-color: #5b9dd9;
    box-shadow: 0 0 2px rgba(30,140,190,.8);
    outline: 2px solid transparent;
}
Legacy textarea style
Legacy focused textarea style

New CSS code:

/* New styles */
textarea {
    box-shadow: 0 0 0 transparent;
    border-radius: 4px;
    border: 1px solid #7e8993;
    background-color: #fff;
    color: #32373c;
}
textarea:focus {
    border-color: #007cba;
    box-shadow: 0 0 0 1px #007cba;
    outline: 2px solid transparent;
}
New textarea style
New focused textarea style

Selects

Legacy CSS code:

/* Legacy styles */
select {
    padding: 2px;
    line-height: 28px;
    height: 28px;
    vertical-align: middle;
    border: 1px solid #ddd;
    box-shadow: inset 0 1px 2px rgba(0,0,0,.07);
    background-color: #fff;
    color: #32373c;
    outline: 0;
    transition: 50ms border-color ease-in-out;
}
select:focus {
    border-color: #5b9dd9;
    box-shadow: 0 0 2px rgba(30,140,190,.8);
    outline: 2px solid transparent;    
}
Legacy select style
Legacy focused select style

New CSS code:

select {
    font-size: 14px;
    line-height: 1.28571428;
    color: #32373c;
    border: 1px solid #7e8993;
    border-radius: 3px;
    box-shadow: none;
    padding: 4px 24px 4px 8px;
    min-height: 30px;
    max-width: 25rem;
    vertical-align: middle;
    -webkit-appearance: none;
    background: #fff url(data:image/svg+xml;charset=US-ASCII,<svg image>) no-repeat right 5px top 55%;
    background-size: 16px 16px;
    cursor: pointer;
}
select:focus {
    border-color: #007cba;
    color: #016087;
    box-shadow: 0 0 0 1px #007cba;
}
New select style
New focused select style

Radiobuttons

Legacy CSS code:

/* Legacy styles */
input[type=radio] {
    border: 1px solid #b4b9be;
    border-radius: 50%;
    background: #fff;
    color: #555;
    clear: none;
    cursor: pointer;
    display: inline-block;
    line-height: 0;
    height: 16px;
    margin: -4px 4px 0 0;
    outline: 0;
    padding: 0!important;
    text-align: center;
    vertical-align: middle;
    width: 16px;
    min-width: 16px;
    -webkit-appearance: none;
    box-shadow: inset 0 1px 2px rgba(0,0,0,.1);
    transition: .05s border-color ease-in-out;
}
input[type=radio]:checked:before {
    content: "\2022";
    text-indent: -9999px;
    border-radius: 50px;
    font-size: 24px;
    width: 6px;
    height: 6px;
    margin: 4px;
    line-height: 16px;
    background-color: #1e8cbe;
}
Legacy radio buttons styles

New CSS code:

/* New styles */
input[type=radio] {
	border: 1px solid #7e8993;
	border-radius: 50%;
	line-height: .71428571;
	background: #fff;
	color: #555;
	clear: none;
	cursor: pointer;
	display: inline-block;
	height: 1rem;
	margin: -.25rem .25rem 0 0;
	outline: 0;
	padding: 0 !important;
	text-align: center;
	vertical-align: middle;
	width: 1rem;
	min-width: 1rem;
	-webkit-appearance: none;
	box-shadow: inset 0 1px 2px rgba(0,0,0,.1);
	transition: .05s border-color ease-in-out;
}
input[type=radio]:checked::before {
	content: "";
	border-radius: 50%;
	width: .5rem;
	height: .5rem;
	margin: .1875rem;
	background-color: #1e8cbe;
	line-height: 1.14285714;
}
New radio buttons styles

Checkboxes

Legacy CSS code:

/* Legacy styles */
input[type=checkbox] {
	border: 1px solid #b4b9be;
	background: #fff;
	color: #555;
	clear: none;
	cursor: pointer;
	display: inline-block;
	line-height: 0;
	height: 16px;
	margin: -4px 4px 0 0;
	outline: 0;
	padding: 0!important;
	text-align: center;
	vertical-align: middle;
	width: 16px;
	min-width: 16px;
	-webkit-appearance: none;
	box-shadow: inset 0 1px 2px rgba(0,0,0,.1);
	transition: .05s border-color ease-in-out;
}
input[type=checkbox]:checked:before {
	content: "\f147";
	margin: -3px 0 0 -4px;
	color: #1e8cbe;
}
input[type=checkbox]:focus {
	border-color: #5b9dd9;
	box-shadow: 0 0 2px rgba(30,140,190,.8);
	outline: 2px solid transparent;
}
Legacy checkbox styles
Legacy focused checkbox style

New CSS code:

/* New styles */
input[type=checkbox], input[type=radio] {
	border: 1px solid #7e8993;
	border-radius: 4px;
	background: #fff;
	color: #555;
	clear: none;
	cursor: pointer;
	display: inline-block;
	line-height: 0;
	height: 1rem;
	margin: -.25rem .25rem 0 0;
	outline: 0;
	padding: 0!important;
	text-align: center;
	vertical-align: middle;
	width: 1rem;
	min-width: 1rem;
	-webkit-appearance: none;
	box-shadow: inset 0 1px 2px rgba(0,0,0,.1);
	transition: .05s border-color ease-in-out;
}
input[type=checkbox]:checked::before {
	content: url(data:image/svg+xml;utf8,<svg image>);
	margin: -.1875rem 0 0 -.25rem;
	height: 1.3125rem;
	width: 1.3125rem;
}
input[type=checkbox]:focus {
	border-color: #007cba;
	box-shadow: 0 0 0 1px #007cba;
	outline: 2px solid transparent;
}
New checkbox style
New focused checkbox style

Buttons

Legacy CSS code:

/* 
 * Legacy styles for buttons
 */

/* General */
.wp-core-ui .button, .wp-core-ui .button-primary, .wp-core-ui .button-secondary {
	display: inline-block;
	text-decoration: none;
	font-size: 13px;
	line-height: 26px;
	height: 28px;
	margin: 0;
	padding: 0 10px 1px;
	cursor: pointer;
	border-width: 1px;
	border-style: solid;
	-webkit-appearance: none;
	border-radius: 3px;
	white-space: nowrap;
	box-sizing: border-box;
}

/* Primary buttons styles */
.wp-core-ui .button-primary {
	background: #0085ba;
	border-color: #0073aa #006799 #006799;
	box-shadow: 0 1px 0 #006799;
	color: #fff;
	text-decoration: none;
	text-shadow: 0 -1px 1px #006799, 1px 0 1px #006799, 0 1px 1px #006799, -1px 0 1px #006799;
}
/* Primary buttons :hover styles */
.wp-core-ui .button-primary.focus, .wp-core-ui .button-primary.hover, .wp-core-ui .button-primary:focus, .wp-core-ui .button-primary:hover {
	background: #008ec2;
	border-color: #006799;
	color: #fff;
}
/* Primary buttons :focus styles */
.wp-core-ui .button-primary.focus, .wp-core-ui .button-primary:focus {
	box-shadow: 0 1px 0 #0073aa, 0 0 2px 1px #33b3db;
}

/* Secondary buttons styles */
.wp-core-ui .button, .wp-core-ui .button-secondary {
	color: #555;
	border-color: #ccc;
	background: #f7f7f7;
	box-shadow: 0 1px 0 #ccc;
	vertical-align: top;
}
/* Secondary buttons :hover styles */
.wp-core-ui .button-secondary:focus, .wp-core-ui .button-secondary:hover, .wp-core-ui .button.focus, .wp-core-ui .button.hover, .wp-core-ui .button:focus, .wp-core-ui .button:hover {
	background: #fafafa;
	border-color: #999;
	color: #23282d;
}

/* Secondary buttons :focus styles */
.wp-core-ui .button-secondary:focus, .wp-core-ui .button.focus, .wp-core-ui .button:focus {
	border-color: #5b9dd9;
	box-shadow: 0 0 3px rgba(0,115,170,.8);
}
Legacy style for primary button
Legacy style for focused primary button
Legacy style for secondary button
Legacy style for focused secondary button

New CSS code:

/* 
 * New styles for buttons
 */

/* General */
.wp-core-ui .button, .wp-core-ui .button-primary, .wp-core-ui .button-secondary {
	display: inline-block;
	text-decoration: none;
	font-size: 13px;
	line-height: 2.15384615;
	min-height: 30px;
	margin: 0;
	padding: 0 10px;
	cursor: pointer;
	border-width: 1px;
	border-style: solid;
	-webkit-appearance: none;
	border-radius: 3px;
	white-space: nowrap;
	box-sizing: border-box;
}

/* Primary buttons styles */
.wp-core-ui .button-primary {
	background: #007cba;
	border-color: #007cba;
	color: #fff;
	text-decoration: none;
	text-shadow: none;
}
/* Primary buttons :hover styles */
.wp-core-ui .button-primary.focus, .wp-core-ui .button-primary.hover, .wp-core-ui .button-primary:focus, .wp-core-ui .button-primary:hover {
	background: #0071a1;
	border-color: #0071a1;
	color: #fff;
}
/* Primary buttons :focus styles */
.wp-core-ui .button-primary.focus, .wp-core-ui .button-primary.hover, .wp-core-ui .button-primary:focus, .wp-core-ui .button-primary:hover {
	background: #0071a1;
	border-color: #0071a1;
	color: #fff;
}

/* Secondary buttons styles */
.wp-core-ui .button, .wp-core-ui .button-secondary {
	color: #0071a1;
	border-color: #0071a1;
	background: #f3f5f6;
	vertical-align: top;
}
/* Secondary buttons :hover styles */
.wp-core-ui .button-secondary:hover, .wp-core-ui .button.hover, .wp-core-ui .button:hover {
	background: #f1f1f1;
	border-color: #016087;
	color: #016087;
}
/* Secondary buttons :focus styles */
.wp-core-ui .button-secondary:focus, .wp-core-ui .button.focus, .wp-core-ui .button:focus {
	background: #f3f5f6;
	border-color: #007cba;
	color: #016087;
	box-shadow: 0 0 0 1px #007cba;
	outline: 2px solid transparent;
	outline-offset: 0;
}
New style for primary button
New style for focused primary button
New style for secondary button
Legacy style for focused secondary button

Darker borders on tables, notices, metaboxes and other similar elements

These changes introduce better contrast for borders for the following user interface elements:

  • Tables
  • Screen Options and Help
  • Admin notices
  • Welcome panel
  • Meta boxes (post boxes on classic editor or in edit attachment screens)
  • Cards
  • Health Check accordions and headings
  • Theme and Plugin upload forms

Legacy CSS code:

Depending on the related element, several CSS declarations were used.

border: 1px solid #e5e5e5;
border: 1px solid #e1e1e1;
border: 1px solid #eee;
border: 1px solid #ddd;
border: 1px solid #e2e4e7;
Legacy card with light grey border
Legacy table with light grey border
Legacy Screen options panel with light grey border
Legacy notice with light grey border

New CSS code:

All those CSS declaration are replaced with a unique color:

border: 1px solid #ccd0d4;
New card with darker border
New table with darker border
Legacy Screen options panel with darker border
New notice with darker border

Related Trac tickets

  • #47153: Field boundaries have insufficient color contrast
  • #34904: The design of the focus outline on buttons/elements could be improved
  • #47477: Content overflows and is cut off at 200% text enlarge
  • #47498: Revise checkbox/radio button css for better compatibility with text zoom
  • #48101: Use darker table + card borders across WP-Admin

#5-3, #accessibility, #dev-notes

WordPress 5.3 Field Guide


Update on 18 October 2019: Added the “Noteworthy Admin CSS changes in WordPress 5.3” dev note to the Accessibility section


WordPress 5.3 is shaping up to be the best WordPress yet! Users will see new blocks, more intuitive block editor interactions, improved media handling, improved accessibility, and the new Twenty Twenty default theme. Among many goodies in 5.3, developers will love the date/time component improvements, PHP 7.4 compatibility, and will also be able to take advantage of 157 enhancements and feature requests, 366 bug fixes, and more! Let’s look at the many improvements coming in 5.3…

Accessibility

Of the 50 updates related to Accessibility in 5.3, you’ll want to particularly note the changes to Admin CSS, improvements of all the media views form controls and changes to explicit labeling, how core will now programmatically add aria-current="page" attributes to certain widgets, and programmatically add specific aria-label parameter for navigation menus. Read the dev notes below for more details on the Accessibility focus.

Block Editor

The block editor has continued its rapid iteration since WordPress 5.0, and now has Gutenberg version 6.5 bundled with WordPress 5.3; that’s TWELVE releases all bundled into 5.3 (versions 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 6.0, 6.1, 6.2, 6.3, 6.4, and 6.5)! Bug fixes and performance improvements from Gutenberg versions 6.6 and 6.7 will also be part of 5.3. The Beta 1 post highlights many of the new features and improvements across these releases, but I’ll specifically pull out the reduction in 1.5 seconds of loading time for a particularly sizeable post (~ 36,000 words, ~ 1,000 blocks) as an impressive achievement given all that has otherwise been added to the block editor. The dev notes below also highlight new server-side block style variations API, a new block example API, the Group block, reduced block styles specificity, using class names for text alignment, Columns block classnames, color support for the separator block, an updates to Table and Gallery blocks markup.

Media

Of the 42 updates for Media in 5.3, you’ll want to particularly note the new way to manage big images by detecting them and generating a “web-optimized maximum size” of them as well as saving of image metadata while creating intermediate sizes. Read the dev notes below for more details on the Media component.

Multisite

Of the 15 updates for Multisite in 5.3, you’ll want to particularly note changes to the database, changes to WP_MS_Sites_List_Table, return for short circuits for multisite classes, and improved performance for site and network lookups by ID. Read the dev note below for more details on the Multisite component.

PHP 7.4 & Code Modernization

The great news continues. WordPress 5.3 supports PHP 7.4, which is scheduled for release at the end of November! Contributors worked with several external libraries to ensure that all 5 tickets addressing compatibility issues for PHP 7.4 were addressed in time for WordPress 5.3.

In addition to ensuring 5.3 supports PHP 7.4, a handful of updates occurred as a result of the continued coding standards and code modernization efforts. Most notably, the spread operator is now in use where appropriate, and the native PHP JSON extension is now required to run WordPress.

Plugin and theme developers are encouraged to read the following detailed dev notes to fully understand the changes coming and how their code should be updated!

REST API

Of the 33 updates for the REST API in 5.3, you’ll want to particularly note register array and object metadata, nested response filtering with _fields query parameter, how to set drafts back to “floating date” status, and possibly best of all up to a 30-40% performance increase in large API responses. Read the dev note below for more details on the REST API component.

Site Health

Of the 31 updates for Site Health in 5.3, you’ll want to particularly note changes to the grading indicator, recovery email enhancements, filters for completed Site Health status tests, and a new Admin email verification screen. Read the dev notes below for more details on the Site Health component.

Other Developer Updates

There are even more goodies in 5.3 like much–needed fixes and a set of improvements to the Date/Time component, changes to prevent search engines indexing sites, new default for links in comments and comment author URLs to use the rel="nofollow ugc" attribute, changes on Twenty Nineteen HTML structure, changes to wp_die() HTML output, expansion of the options available to compare_key so that developers have access to meta-key comparison operators similar to those available for meta values, updates related to bumping the Backbone version bundled with WordPress from v1.3.3 to v1.4.0 and other external library updates, dropping support for integer menu slugs, addition of a “Show” button next to the password field on the login screen, passing arrays to supports argument when registering post types, HTML5 support for script and style arguments, recording additional information for saved queries, unit-less CSS line-height values, updates to cores’ build/test tools, and more! Read through the dev notes below to see what else is coming in 5.3.

But Wait, There is More!

Over 362 bugs, 157 enhancements and feature requests, and 36 blessed tasks have been marked as fixed in WordPress 5.3. Some additional ones to highlight include:

  • General: Use ** operator to replacepow() function calls (#48083)
  • I18n: Text length should be localizable (#44541)
  • Menus: Replace http with https in custom links menu item (#46312)
  • Networks and Sites: Redundant blog_versions table (#19755)
  • Networks and Sites: Save database version in site meta (#41685)
  • Site Health: Provide simple debug data in WSOD emails (#48090)
  • Widgets: Replace http with https in the link placeholder widget image (#46320)

Please, test your code. Fixing issues helps you and helps millions of WordPress sites.

#5-3, #field-guide

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 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

Actions

There are a few action hooks 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 tag, 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.

Filters

One new filter, 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:

<?php
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:

<?php
add_filter( 'admin_email_check_interval', '__return_false' );

For more information about these changes, check out #46349 in Trac.

Props to @desrosj for peer review.

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

The REST API in WordPress 5.3

WordPress 5.3 contains a number of REST API improvements designed to make it easier and faster to work with API data from the block editor or other client applications.

Register Array & Object Metadata

As covered previously in this developer note on array & object metadata, it is now possible to use register_post_meta & register_term_meta (as well as the underlying method register_meta) to interact with complex meta values as schema-validated JSON arrays or objects using the REST API. See the linked post for more details.

Nested response filtering with _fields query parameter

This developer note on the changes to the REST API’s _fields= query parameter shows how you may now filter your REST API response objects to include only specific nested properties within the response body.

Ticket #42094

Set drafts back to “floating date” status

Once a date has been set for a draft, it was previously impossible to set the post back to showing “publish immediately” (also referred to as a “floating date,” where the post will be dated whenever it is published). As of 5.3, passing null for a date value will unset the draft date and restore this floating state.

Ticket #39953

Faster Responses

We have introduced a caching wrapper around the generation of REST resource schema objects, which initial testing has shown to yield up to a 30-40% performance increase in large API responses. If you work with expensive or large REST API queries, things should be quite a bit faster now. (Ticket #47871)

The REST API has also been improved to avoid unnecessary controller object instantiation (#45677) and to skip generation of sample permalinks when that data is not requested (#45605).

Please Note: if your team has existing performance benchmarking tooling for the REST API, please contact the component maintainers in the #core-restapi Slack channel; we very much desire to expand our metrics in this area.

Additional Changes of Note

In addition to these key enhancements, there are a number of smaller improvements to the REST API which may be of interest to developers.

  • It is no longer possible to DELETE a Revision resource using the REST API, as this behavior could break a post’s audit trail. Ticket #43709
  • The /search endpoint will now correctly embed the full original body of each matched resource when passing the _embed query parameter. Ticket #47684
  • rest_do_request and rest_ensure_request now accept a string API path, so it is possible to instantiate a request in PHP using nothing more than the desired endpoint string, e.g.
    rest_do_request( '/wp/v2/posts' );
    Ticket #40614
  • Creating or updating a Terms resource via the REST API now returns the updated object using the “edit” context. Ticket #41411
  • It is now possible to edit a posted comment through the REST API when authenticating the request as a user with the moderate_comments capability. Previously a full editor- or admin-level role was needed. Ticket #47024
  • rest_get_avatar_urls now receives the entire User or Comment object, not just the object’s email address. Ticket #40030

Welcoming Timothy Jacobs as a REST API component maintainer

Last but not least, many of you have no doubt seen @timothyblynjacobs active in trac, slack, and community events. Timothy has driven much of the momentum that resulted in the above improvements, and I’m excited to (belatedly) announce that he has joined the REST API team as an official component maintainer. Thank you very much for your energy and dedication!

Thank you also to every other person who contributed to API changes this cycle; it’s the best version of the REST API yet, and we couldn’t have done it without the dozens of contributors who helped create, review and land these patches.

We’ve got some ambitious ideas about how we can make the REST API even better in 5.4. Interested in helping out, with code, docs, or triage? Join us for weekly office hours, every week on Thursdays at 1800 UTC!

#5-3, #dev-notes, #rest-api

Dev Chat Agenda for October 16 2019 (5.3 week 9)

Here is the agenda for the weekly meeting happening later today: Wednesday, October 16, 2019, 20:00 PM UTC. Please share any items you’d like to include in the comments below!

  • Announcements and highlighted posts
  • Upcoming Release Discussions
  • Calls from component maintainers
  • 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 #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-3, #agenda, #dev-chat

Report: WP 5.3 Admin CSS changes tested against top 20 plugins

In September 2019, the WordPress Accessibility team tested WP 5.3 Admin CSS changes against the Top 20 plugins on WordPress.org, to evaluate possible breakage on plugins admin screens and to iterate on the related changes.

This week, those tests were reproduced against 5.3-beta3-46471. This post is a report illustrated with screenshots of relevant admin screens for each plugin.

The idea was to test Admin CSS changes against various use cases to see what could happen and to fix as many found bugs as possible. Of course, not every use cases are covered in 20 plugins, but the Accessibility team assumes it will provide a general view on the robustness of the changes coming in WP 5.3.

A dev note will quickly follow this post, to communicate on all the CSS changes coming in WP 5.3 admin screens to plugin authors and WordPress developers.

To sum up, some plugins which use custom CSS that override WordPress Admin default CSS rules on form controls may have few minor visual glitches. Most notably: the input fields can be taller than before WP 5.3. There’s no breakage as the input fields are fully operable, but plugin authors and WordPress developers are encouraged to:

  • remove any fixed heights: flexible heights are the WordPress recommended standard (and one of the main goals of the Admin CSS changes)
  • remove any custom top and bottom padding values
  • remove any custom line-height values

For each plugin, screenshot are provided. You can click them to see the full media file.

Contact Form 7

This plugin uses default core admin styles. No breakage found.

Yoast

This plugin uses both custom styles and default core admin styles. No breakage found. One input and one button are too close to each other in the search appearance page. Looks to be due to incorrect use of margins.

Akismet

This plugin uses both custom styles and default core admin styles. No breakage found.

Classic Editor

This plugin uses default core admin styles. No breakage found.

Jetpack

This plugin uses custom styles. No change found on the screens audited. Further exploration could be needed on specific admin screens. Edit: Jetpack team is already working on some small CSS changes in a dedicated pull request. Worth a read to see how plugins could handle Admin CSS changes.

WooCommerce

This plugin uses both custom and default admin styles. Two misaligned labels were found in the installation screen. Some inputs have large vertical paddings/heights. No breakage found.

Note: WooCommerce team already worked on Admin CSS changes in a dedicated pull request. An interesting read to see how plugins could handle Admin CSS changes.

WordPress Importer

This plugin uses default admin styles. No breakage found.

Really Simple SSL

This plugin uses both custom and default admin styles. No breakage found.

Elementor Page Builder

This plugin uses both custom and default admin styles. Small misalignment in one (screenshot 6) of the dozen pages of settings, due to fixed margins. Pretty minor though. No breakage found.

Wordfence Security

This plugin uses both custom and default admin styles. No breakage found.

Duplicate Post

This plugin uses default admin styles. No breakage found.

TinyMCE Advanced

This plugin uses both custom and default admin styles. No breakage found.

All in One SEO Pack

This plugin uses both custom and default admin styles. No breakage found.

WP Forms

This plugin uses both custom and default admin styles. No breakage found.

Google XML Sitemaps

This plugin uses default admin styles. No breakage found.

Google Analytics Dashboard Plugin for WordPress

This plugin uses custom admin styles. No breakage found but the test couldn’t handle each screen of the plugin due to the some issues with plugin’s configuration on local installs.

All-in-One WP Migration

This plugin uses both custom and default admin styles. No breakage found.

UpdraftPlus Backup

This plugin uses both custom and default admin styles. No breakage found.

WP Super Cache

This plugin uses default admin styles. No breakage found.

Google Analytics Dashboard for WP

This plugin mixes custom and default admin styles. No breakage found.


Please note this report is only including Top 20 plugins from WordPress.org, but the changes were also tested on various others plugins, such as WP-Rocket, Advanced Custom Fields, Polylang… and dozens of plugins with less active installations.

#5-3, #accessibility, #testing