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.4 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 17:30 UTC at #design Gutenberg Design Triage: Every Tuesday 17:00 UTC at #design Accessibility Scrub: Every Friday 14:00 UTC at #accessibility
Also, the ongoing APAC-friendly #core bug scrub session every Thursday at 06:00 UTC will continue during the cycle, alternating focus between core and editor.
Next, the Accessibility team has announced a few extra scrubs for the 5.4 cycle. You can read about those here.
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.4-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.4, 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.
WordPress 5.4 introduces two new actions that can be used by developers to add custom fields to menu items, in both the Menu screen and the Customizer’s menu editor.
The following hooks are now available:
Menus admin screen
WordPress 5.4 introduces wp_nav_menu_item_custom_fields action, that fires just before the move buttons of a nav menu item in the menu editor.
Five parameters are available:
$item_id: the menu item ID (integer)
$item: the menu item data object (object)
$depth: the depth of the menu item (integer)
$args: an object of menu item arguments (object)
$id: the Navigation Menu ID (integer)
Here is a simple example of using wp_nav_menu_item_custom_fields:
function wporg_my_custom_field() {
esc_html_e( 'Howdy! WordPress 5.4 is coming!', 'wporg' );
}
add_action( 'wp_nav_menu_item_custom_fields', 'wporg_my_custom_field' );
And here is the result (with an additional green dashed border):
Customizer’s menu editor
WordPress 5.4 introduces wp_nav_menu_item_custom_fields_customize_template action, that fires at the end of the form fields template for navigation menu items in the customizer.
Additional fields can be rendered here and managed with JavaScript.
This brings parity with the wp_nav_menu_item_custom_fields action.
Compatibility with existing custom walkers
Plugin authors and WordPress developers are invited to check their existing code to replace the custom walkers they use for navigation menu fields with these new action hooks.
For further information, see the related Trac ticket: #47056.
Another ticket could help plugins authors and WP developers to deal with custom fields duplication: #49500. Checking for WordPress version is the recommended way for plugins authors to avoid this issue.
This is the agenda for the weekly editor chat scheduled for 2020-02-26 14:00 UTC. This meeting is held in the #core-editor WordPress Slack channel.
WordPress 5.4 Upcoming Release
Gutenberg version 7.6.0
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. If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.
Since lazy-loading images via the native loading attribute was proposed for addition to WordPress core, there have been quite a few updates. With the WordPress 5.4 release cycle entering beta almost two weeks ago, there was too little time for testing the feature plugin and creating a proper core patch. The feature is now aimed at being released as part of WordPress 5.5, to be merged early in the release cycle to get further testing while fully integrated with the platform. This post is a follow-up to the original announcement, providing information about the latest updates.
Standardization of the loading attribute
The WHATWG spec pull-request for adding the loading attribute to img elements with possible values “eager” and “lazy” was recently merged, so it is now part of the HTML Living Standard (see general paragraph about lazy loading attributes and more specific information about the imgloading attribute). This was a requirement for WordPress to ship with support for the feature. While it was unclear whether this was going to happen in time for the WordPress 5.4 release (which it now has), the 5.5 timeline certainly works for it, as now the feature can be merged way ahead of the initial beta.
Browser support
At the time of this publication, Chrome (76+), Edge (79+) and Opera (64+) already support the loading attribute. Firefox support was merged recently, and is intended to land in version 75. WebKit support is actively being worked on, so seeing the feature land in Safari is also on the horizon. We will monitor how browser vendors are adopting the standard, but with recent developments it looks promising. All major browsers will support the loading attribute by the time WordPress 5.5 is released (currently 2020/08/11). Please refer to caniuse.com for current updates.
State of the feature plugin
The feature plugin for lazy-loading images in WordPress core (GitHub repository) is in a good state to be used already. The exact implementation is undergoing some changes, mainly focused on optimizing the mechanism to add the loading attribute to images in post content for performance by combining it with the existing regular expression in core that adds srcset and sizes attributes. These changes will likely affect the new APIs outlined in the original post, and a dev note about the definite state will be published closer to the WordPress 5.5 release.
The plugin is ready to be widely tested. It has already undergone some testing, but we are looking for more testers! We will also like to receive any type of feedback on the implementation.
We had quite a few people attending, not all of whom were familiar with the project. Thus, we started off with a small recap of the project’s scope and goals. After that we discussed various different topics:
How to modify the sitemaps to include/exclude certain URLS A pull request has been opened to add a FAQ section to the readme that aims to answer these kind of questions. Also, a new way to filter WP_Query instances used for sitemaps has been proposed.
Why are there no changefreq and priority fields? Those are optional fields in the sitemaps protocol and not typically consumed by search engines. The feature plugin follows other solutions like Yoast SEO who also don’t include those fields. Developers can still add those fields if they really want too.
Will there be UI controls to include/exclude content from sitemaps? Adding UI controls is currently a non-goal for the project.
Calculating the last modified date for URLs This is rather difficult and computationally expensive in WordPress. Given that sitemaps are first and foremost a discovery mechanism for content, having this data is not necessarily required. We will explore omitting this functionality (GitHub issue).
The default limit of 2000 URLs per sitemap is considered high and might need to be re-evaluated.
Potential compatibility issues with other XML Sitemaps plugins have been discussed. If a site ends up having two sitemaps by accident that wouldn’t be bad. However, the current /sitemap.xml URL might clash with other plugins. A GitHub issue has been opened to suggesting using /wp-sitemap.xml as the base. This would avoid conflicts in this regard.
5.4 Beta 3 is scheduled to be released on February 25, 2020. (Note to committers and maintainers, the cut off time to get bugs fixed and into WP 5.4 is February 25th, 20 UTC)
5.4 is intended to be released March 31st, 2020.
Agenda
Status report on the About page – content and design
Dev Notes status and how to proceed to get them all published in time for RC1 and the Field Guide.
@audrasjb suggested it would be great to schedule one or two bug scrubs before the next beta so we can punt/help the 134 remaining tickets in the milestone. @francina “seconded” with a call out for anyone who has spare time to help organize a bug scrub (See this post for how to run one). Open tickets for 5.4 can be found here (in order of priority). The Bug Scrub schedule for 5.4 lists scheduled scrubs for anyone to join in.
Status Report on the About Page – Content and Design
@karmatosed stated everything is lining up to start the About page earlier this release. There will also be a push to document this. @melchoyce and @elmastudio are leading the design charge on this with @marktimemedia riding along to observe. @marybaum added they’ve got chunks of the copy written and she promised to share it with major-release-squad.
Dev Notes Status
..and how to proceed to get them all published in time for RC1 and the Field Guide.
@audrasjb reports since the last dev chat, four new dev notes were published:
@audrasjb also reports to date, they have a dev note published for about 50% of closed tickets with the `needs-dev-note` keyword in the milestone and 4 drafted dev notes ready to publish. He is very confident they’ll have all dev notes published by the end of the month (during last week before RC1)
@jorgefilipecosta reports he is tracking the progress of the block editor related dev notes and requests that any feedback before the dev notes are published would be great as the content there was not yet reviewed and is just what the original people involved in a PR think the dev note should contain.
@johnbillion asks that if anyone sees changes going into core that they think need a dev note, to leave a comment on the ticket. @audrasjb adds “if you think there are some important tickets that don’t have the `needs-dev-note` keyword, please get in touch with me”. @azaozz asks that you ensure the dev notes are really for developers and are concise and to the point and preferably with a code example of changed usage. @jorbin reminds us to remember the guidelines for posts and the need to have a peer review.
@francina thinks having a separate page with guidelines on submitting dev notes would be helpful. @earnjam mentioned @desrosj would have a draft written up on the subject.
@francina announced the highlighted post. There were no comments.
Component Check-ins
News from Components
Components up for adoption (i.e. looking for maintainers): Filesystem API and Rewrite Rules
Components that need help
Cross component collaboration
News From Components
Administration
@valentinbora reports 1 week after he took up Administration, 40+ tickets have been triaged with 2-3 moved to other components. Per the previous meeting’s discussion regarding the very existence of the Administration component, @valentinbora thinks it’s here to stay.
Gutenberg
@jeffpaulraised the issue of Gutenberg development overlapping existing Core components and how to best communicate with their respective maintainers/teams. @francina proposed a continued discussion about the cooperation between Components and Gutenberg out of the meeting.
Widgets & Menus
@audrasjb noted 3 bug fixes with `commit` keyword and concerns about managing the transition and backward compatibility with tickets referring to current widgets/menus and new tickets referring to full site editing (FSE).
@noisysocks recommends that maintainers of the widgets, customizer and editor components get involved and look at the relevant labels in the Gutenberg repository.
Open Floor – Announcement
@pbiron announced that a new version of the WordPress Beta Tester plugin was released earlier today with a new feature. On the settings screen (`Tools > Beta Testing`), once you’ve already updated to either `Point release nightlies` or `Bleeding edge nightlies`, you’ll see a new option for `Beta/RC`. Once you’ve set that as your current stream, you’ll only be updated when the next beta or RC (or official) is released rather than the nightlies.
One advantage of this new feature is that you’ll be able to update to beta or RC packages right in the Dashboard (Dashboard > Update) as soon as the packages are built during the release parties if you’re not comfortable using wp-cli. Hopefully, this will increase the pool of testers during the release parties.
As the meeting was over time, the remaining two topics from today’s agenda were not started.
Action Items
These items were discovered within the content as stated action items.
@francina to add the bug scrubs to the meetings page (like she did for 5.3)
@francina to add “creating a separate page with dev note guidelines, adding comments to a ticket” to her desiderata. Check with @desrosj who might have a draft of a page with details about how to write a good dev note.
@audrasjb and @welcher should look at Widgets/Menus issues/PR on Gutenberg
@noisysocks to add a ‘call for volunteers’ to the next core editor chat to implement proactive communications from Gutenberg to those component maintainers to help find ways to work together.
@jeffpaul suggests we call out notice to the new WordPress Beta Tester plugin in the Beta 3 blog post (and future posts as well) so folks looking to help test have a starting place.
@clorith wants to chat about how to move more things into a React world and how to do it outside of Gutenberg.
@noisysocks to “put something up” on Make/Core to continue the conversation about cooperation between Components and Gutenberg (i.e. Cross Teams Collaboration).
WordPress development uses SVN, but many contributors prefer to work in Git through GitHub. For some contributors, that means working with a cumbersome workflow within Trac. Many contributors create pull requests using their own forks of the official WordPress Develop mirror so that they can use features like continuous integration and inline code commenting. Historically, though, it has been hard to cross-reference between the two systems.
Starting today, an experimental feature has been added to Trac that will let you link GitHub pull requests opened against the official WordPress Develop Git mirror to tickets. This makes GitHub contributions more visible directly in their related Trac tickets and makes collaborating across the two repositories easier. (Better contributor experiences, ftw!)
Note: this is not a signal of any decision to start moving WordPress to Git, GitHub, or GitLab. That is something that is still being explored separately and independent of this feature. There is no further update on that at this time.
The PR will be displayed below the attachments area on tickets with the following information:
How many lines were modified
Status of the PR checks (Draft/Closed, Travis CI, merge conflicts, etc.)
A button to view the PR
A button to view the raw diff
A bot comment will be added to the ticket’s timeline of events indicating when the ticket was mentioned and where.
Every time the PR receives a comment, a PR bot will post the comment onto the Trac ticket.
Pull requests show between Attachments and Change History.
Important Notes
Trac remains the source of truth for all discussion. If you prefer to continue working in Trac, that’s OK! Nothing will change on Trac itself other than what is noted above. Nothing about how you contribute has to change!
When the PR bot syncs comments over to Trac, it will not trigger an email notification to the subscribers of the Trac ticket. For this reason, it is recommended to provide some type of ticket update in Trac itself. Most likely there will be a need to update the keywords anyway (add has-patch or needs-testing, etc.).
Comments made during a code review on the PR will not be posted to the Trac ticket. These comments are usually specific to the code being reviewed, so this should be OK. If this causes confusion, syncing these can be explored.
No changes to WordPress Core will be merged through GitHub pull requests. This is not new and remains the same. This feature is meant to make contributions done through PRs on GitHub more transparent in Trac.
Pull requests on GitHub are not monitored. No one will be checking for new pull requests regularly. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core.
Clean up after yourself occasionally. Right now, PRs are not automatically closed when the associated Trac ticket is resolved. If you open a PR, do your best to close PRs that have been merged into Core whenever you are able to.
And finally, this is an experiment. There will likely be some small bugs and things that can be improved since this is the first iteration. Please open up tickets in Meta Trac for any issues that you find. All feedback is welcome! Please leave your thoughts in the comments of this post below.
I proposed a question to reflect on for this and future meetings: “What, if anything, should we improve about our CSS in core and/or gutenberg? And what, if anything, are we already doing particularly well? “ (If anyone reading this would like to contribute an answer, feel free to pop into the next meeting, or just add a note to the agenda if you can’t make it to the actual meeting!)
@bemdesign expressed concern that the adoption of modern development approaches, especially CSS-in-JS, and the build tooling necessary for React apps, might over-complicate the process for new developers to get started.
We discussed how to ease the learning curve and make it easier for new developers to get involved:
Choosing tools with an easier syntax (in the CSS-in-JS case)
Education and documentation
Out-of-the-box build configs, such as @wordpress/scripts
Then, going back to the initial question, @peterwilsoncc suggested overly high specificity of some CSS selectors could be improved, and ideally we should have a consistent level of specificity throughout.
@youknowriad added that we should try to create style variations in components instead of trying to override default component styles with additional classnames.
@laras126 suggested using single-declaration utility classes that sit further down the cascade, and passing in classnames as props.
We agreed backward compatibility may make it hard to change our current approach completely.
We briefly discussed how a new version (CSS4) might be useful to us: adding visibility to current best practice approaches and as an encouragement to developers to learn the spec better.
One thing I’ve become curious about is how some components should potentially be looking to support current/future phases of Gutenberg? Thinking here about Customizer, Widgets, Menus, and the like. Is there anyone on the Gutenberg team that’s working with those components to see how those maintainers/contributor teams could help advance Gutenberg development from their unique perspective from a core component team?
Some discussion ensued, but it’s an important topic that’s worth discussing in an asynchronous forum where people from all timezones can participate.
So: How do we ensure that there is good collaboration between Component Maintainers and the Gutenberg project?
We opened by reviewing the Use Cases section. We moved an item related to which users plugin or theme notifications should be shown to, down to a later section in the document (Wish List Items), to be discussed at the relevant time.
@folletto noted that “here we are a bit playing a double role, use cases for users and use cases for developers. These luckily overlap a bit, and I think what we have is a good compromise”. @psykro left a comment that we might need to expand on use cases. We also had a brief discussion about the section on state changes. While the ultimate goal would be for WP Notify to replace those as well, this might not happen in our first release.
We reviewed the current status of the new Current Status section and had a discussion on the terminology related to the different types of notifications. @folletto suggested the following:
Notification = a notification hub, with maybe a dropdown or a container of some sort, that shows alerts across pages
On Page = a local notification, shown only on a specific page, and contextual to the page content
Finally we removed the admin_notices graphic from the Current Status section.
As always, we invite the community to share their feedback on any of these changes to the document, either here in the comments or on the document itself.
