The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
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.
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:
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.
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.
@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.)
@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.
@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.
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.
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.
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!
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.
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.
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.
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.
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!
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.
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.
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.
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)
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:
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.
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.
The user clicks “Remind me later”: the user is taken to the Dashboard. Administators will see the screen again after 3 days have passed.
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:
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.
@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).
@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.
@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.
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
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.
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!
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.
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.
