Bug Scrub Schedule for 5.3

Now that 5.3 has been officially kicked off, bug scrubs will happen weekly all the way up to the final release. Keep an eye on this schedule – it will change often to reflect the latest information.

  1. 8/27/2019 18:00 UTC
  2. 9/5/2019 14:00 UTC
  3. 9/12/2019 05:00 UTC (APAC-Friendly)
  4. 9/18/2019 23:00 UTC
  5. 9/25/2019 17:00 UTC
  6. 10/2/2019 16:00 UTC
  7. 10/9/2019 17:00 UTC Led by @marybaum
  8. 10/17/2019 17:00 UTC
  9. 10/23/2019 TBD (If Needed)
  10. 10/30/2019 TBD (If Needed)

These scrubs are separate and in addition to the normal scrubbing and triage by individual components. Some of those sessions include:

Design Triage: Every Monday 16:30 UTC at #design
Gutenberg Design Triage: Every Tuesday 16:00 UTC at #design
Accessibility Scrub: Every Friday 14:00 UTC at #accessibility

Also, @pento recently announced a new, ongoing APAC-friendly #core bug scrub session every Thursday at 06:00 UTC.

As the release date nears, one-off, “flash” scrubs pop up for individual components. These are typically focused on a specific group of tickets or an individual feature. Some of these sessions include:

Twenty Twenty Theme Scrub: 9/20/2019 16:00 UTC at #core-themes
Media Accessibility Scrub: 9/23/2019 06:00 UTC at #core-media (APAC-Friendly)
Media Accessibility Scrub: 9/25/2019 14:00 UTC at #core-media
Accessibility Scrub: 10/1/2019 16:00 UTC at #accessibility

Finally, a reminder that anyone — Yes, you! — can host a bug scrub at anytime. You can work through any tickets you’re comfortable with. In fact, if you plan one that’s 5.3-focused, we’ll add it to the schedule here along with your name. Finally, you’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

All open tickets for 5.3, in order of priority, can be found here. Tickets that haven’t seen any love in a while are in particular need. Those can be found in this query.

If you’d like to lead a bug scrub or have any questions or concerns about the schedule, please leave a comment or reach out to me directly.

#5-3, #bug-scrub

Dev Chat Summary, October 16, 2019

@francina led off a well-attended dev chat – 29 active participants! – with the standard introduction and remarked that we were in Week Nine of the release cycle.

Announcements and Highlighted Posts

She issued a call for announcements and highlighted posts, then announced that WordPress 5.3 Release Candidate 1 had landed the day before, on October 16.

@azaozz and @sergey were our packagers; @francina and @desrosj led the process.

Dev Notes

@johnbillion called the group’s attention to a crop of new dev notes as a way to keep up with changes in 5.3 for devs; @justinahinon linked to the 5.3-specific ones here.

@jeffpaul added that pending one more dev note, the Field Guide will publish shortly.

Accessibility testing in the 5.3 Admin

@francina directed the group to this report from @audrasjb on accessibility testing of the CSS changes coming to 5.3 against the 20 most popular plugins on the WordPress.org repository.

@francina thanked @jeffpaul for the Field Guide and @ipstenu for plugin support.

Upcoming Releases

5.3

@francina‘s call for updates prompted mostly murmurings that everything’s progressing on schedule. @azaozz pointed out there were only a couple of new tickets after RC1, and @desrosj had three to call out for reviews from other committers: #48022, #48312, #47699.

(Remember that after RC1, every commit needs signoff from two committers, not one, until launch.)

Discussion of a related ticket, #48331, followed.

Calls from Component Maintainers

@francina opened the calls from component maintainers.

@jeffpaul: Not a component maintainer update, but worth noting that during the RC1 packaging process (I believe) we confirmed that trunk would be opened back up after RC2.  That may be worth confirming here and noting in the devchat summary post which you’re reading now)

@sergey and your faithful but tardy reporter confirmed that we’ll start milestoning for 5.4 at that point, and @desrosj pointed the group to the RC1 discussion here.

The final announcement from @davidbaumwald was this:

@committers Committing to Core is now open again.  Reminder, now that we’re in RC, the dev-feedback and dev-reviewed workflow is required prior to committing, where each commit must get double-signoff.

@desrosj pointed out that 5.4 already has 94 tickets. He encouraged the group and observers (and you, dear reader!) to address these 94 tickets first or punt them if they’re unrealistic.

Open Floor

@francina had two items.

RC2

RC2 is tomorrow, October 22. @francina asked the group for a team and a timeline; discussion followed about some last-minute changes that we won’t be making tomorrow.

Workflow for the About Page

@francina also opened the floor to a discussion about whether or not the About Page can get locked down 24 hours before a release. For the most part, the group agreed that much of the page can, but there will always be a few last-minute fixes — especially for majors.

See you tomorrow for the launch of RC2!

#core, #devchat, #summaries

WP Notify weekly meeting agenda for 21 October 2019

Here is the agenda for the weekly meeting happening later today, Monday, October 21, 2019, 14:00 UTC and Monday, September 21, 2019, 22:00 UTC.

  • Opening and welcome
  • Discussion: What is the objective of this project?
  • Update on requirements gathering process
  • Open floor

If you have anything specific to propose for the agenda, 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

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

Javascript Chat Summary – October 15, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Major props to @cbravobernal for wrangling it.

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Storybook

Storybook is a UI component explorer for frontend developers and designers.

@gziolo created a new label Storybook on GitHub to make it easier to discover related issues and PRs in Gutenberg.

In the meantime, contributors @mkaz and @itsjonq added the first stories with examples of UI components available at https://wordpress.github.io/gutenberg/design-system/components/?path=/story/introduction–page.

Adding @wordpress/components in Storybook is a straightforward way to start, as they are already some existing examples. Many people also voiced many advantages of using Storybook, emphasizing the easy way to explore which components Gutenberg provides.

The team also talked about benefits for having the master issue overview of the effort and a way to track progress.

@gziolo raised the issue of using Netlify for the playground and Storybook previews in PRs. Netlifly offers a special free plan for OSS projects but they require a link to be included on the project page which is something which might not work in the case of WordPress.

Action items:

  • create the master issue with the next steps for Storybook (@gziolo)
  • create individual issues with improvements to the Storybook setup (owner required)
  • discuss live preview for PRs and explore various options (owner required, with @nerrad ready to pick it up at a later time)

Monorepo – Mobile Gutenberg

The next topic was moving the Mobile Gutenberg codebase into the Gutenberg monorepo. @hypest opened the original issue nearly a year ago!

There is a draft PR which moves most of the code from wordpress-mobile/gutenberg-mobile respository to npm packages in WordPress/gutenberg repository.

@hypest requested help from someone with good web knowledge in order to check if that PR is going to cause any issues.

Action item: 

@gziolo will check this PR and help to merge once WordPress trunk is frozen during the process of the 5.3 release.

#javascript, #meeting-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

Core editor chat summary 16th October, 2019

This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 16th Oktober 2019 held in Slack. Moderated by @jorgefilipecosta.

Gutenberg 6.7
A new version of Gutenberg (6.7) was released this morning.
It includes lots of important bug fixes that were cherry picked and should also be part of WordPress 5.3. If you are finding any problem with this release please let us know or create an issue. This release was mostly about stability or performance. But includes Gradient backgrounds as a relevant feature. For more information see the release post: What’s new in Gutenberg? (16 October)

Weekly Priorities

Gradients: Theme support, classNames, custom UI.
Full site editing: Site Title block, rendering engine, temporary template editing UI and start working on the multi-entity saving UI.
Improvements to the link UI (a bit mid-term goal).
Complex block interactions.
https://github.com/WordPress/gutenberg/issues/13202
Some requirements are needed before that: selection mode 
https://github.com/WordPress/gutenberg/issues/17088 and better drag and drop.

A new Link UI comment made by @get_dave.
Issue: https://github.com/WordPress/gutenberg/issues/17557
PR: https://github.com/WordPress/gutenberg/pull/17846
A mention:
@jorgefilipecosta
To create a storybook for the new component to allow easier testing.
@youknowriad
Current storybook is only for wordpress/components and this is a wordpress/block-editor component if I’m not mistaken so there’s some organisation/thinking to do here.
@jorgefilipecosta
I guess it would also make sense to use storybook for components under block-editor.

Storybook links:
“Build bulletproof UI components faster” https://storybook.js.org/
WP Storybook for components: https://wordpress.github.io/gutenberg/design-system/components
Check the Core Editor discussion for more information.

Task Coordination

@youknowriad
I’m planning to review Full Site Editing and UI components (Card) related work. Work on the selection tools (breadcrumb and edit/select tools).

@andraganescu
Smart block appender
https://github.com/WordPress/gutenberg/pull/16708
Add horizontal option for the block movers
https://github.com/WordPress/gutenberg/pull/16615
Media Flow Component
https://github.com/WordPress/gutenberg/pull/16200
Also I will be reviewing as much as possible the two new Navigation Block PRs: navigation: Navigation customization
https://github.com/WordPress/gutenberg/pull/17832
Unified Link creation interface
https://github.com/WordPress/gutenberg/pull/17846

@gziolo
Finish or close all my open PRs which didn’t get to 5.3.

@karmatosed
Plan on picking up some ‘needs design’ that have been sat a while around smaller screen experience, for example buttons vanishing.
Giving design feedback the link interface iterations. https://github.com/WordPress/gutenberg/pull/17846#issue-325799134
Give feedback on the audit work.. come join me! https://github.com/WordPress/gutenberg/issues?q=is%3Aissue+is%3Aopen+audit+label%3A%22Needs+Design+Feedback%22

@brentswisher
I plan on continuing on adding a notice of disabled blocks to block inserter when no results are found. Look into options for starting a new post in “editing” vs. “navigation” mode of the writing flow.

@koke
Template selector for new pages in the mobile apps. I have to catch up with the current Full Site Editing state and see how that would overlap with existing plans, and if the feature makes sense for core/web. I hope to have something more concrete to propose/discuss next week.

@vindl
I’ll try to write up some feedback and proposals on Block templates for Full Site Editing https://github.com/WordPress/gutenberg/issues/17512 based on the work and takeaways from https://wordpress.org/plugins/full-site-editing/

@mapk
Reviewing some of the block pattern work: https://github.com/WordPress/gutenberg/issues/17335
Helping to keep the drag n drop of images issue rolling. https://github.com/WordPress/gutenberg/issues/13202

@jorgefilipecosta
I will work on the Gradient related tasks on the priority list. I hope to submit a core patch to fix a kses rule to allow gradient styles for contributor roles. Besides the gradients related work, I will continue the work on the block style improvements.

@retrofox
Currently working on customization. The PR is really advanced. Feedback is more than over welcome!
Issue: https://github.com/WordPress/gutenberg/issues/17683
PR: https://github.com/WordPress/gutenberg/pull/17832

@mkaz
So I’ll continue to add components to storybook.

Open Floor

@brentswisher
In working on updates to the inserter https://github.com/WordPress/gutenberg/pull/17338 and it was pointed out that I can not use packages from edit/post in the inserter.
Check the Core Editor Slack discussion for more information.

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

What’s new in Gutenberg? (16 October)

Work on stability and performance continues, and these bug-fixes have now been included in WordPress 5.3 RC 1.

In addition, this release starts the work on gradient backgrounds. First, the support is added to the Button block. Improvements to the gradients palette API and support in more blocks will be worked on for future releases.

Storybook

For Developers, this release also introduces a Storybook.

Accessible on this link for the master version, but also available on each Pull Request (https://deploy-preview-{PR_number}--gutenberg-playground.netlify.com/design-system/components/). Storybook is an isolated environment where the reusable WordPress UI components (@wordpress/components) are developed, tested and showcased.

Down the road, the netlify integration and the exact URLs can be adapted. This tool is meant to be directly integrated into WordPress Developer Docs.

6.7

Features

Bug Fixes

Performance

Enhancements

Experiments

Documentation

Various

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 6.7.0 5.52s 51.98ms
Gutenberg 6.6.0 5.57s 51.47ms
WordPress 5.2 6.53s 61.13ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Editor Chat Agenda: October 16th

Note taker: @paaljoachim

This is the agenda for the weekly editor chat scheduled for Wednesday, 16th October 2019, 13:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • Gutenberg 6.7
  • Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

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

#agenda, #core-editor, #editor-chat