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.
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 though 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.).
Inline comments made during a code review on the PR will not be posted to the Trac ticket. These comments are contextual to specific lines at a specific state (commit) of a PR, 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.
The release contained several fixes for the editor. A few notable items:
Block editor: Columns in the Block Library that have unassigned-width will now grow equally.
Block editor: The custom gradient picker now works in languages other than English.
Block editor: When choosing colors is not possible, the color formatter no longer shows.
Everything can be viewed here. We still have some ongoing work in the must have board. Props to all involved in the process, with the big shootout to @jorgefilipecosta for wrangling all the boring work of syncing all those fixes in WordPress core. Friendly reminder for those who are aware and explanation to everyone else about the workflow during WordPress release cycle. Next release will be the last beta version. That means the first RC and the string freeze is very close. Until WordPress 5.4 is out, we do the regular release for the plugin every 2 weeks. At the same time, we only backport essential bug fixes to WordPress core. It means that we don’t do regular publishes to npm for WordPress packages.
The dev notes work is going well and post notes are already written. Thank you to all the helped this effort and wrote dev notes
FSE ongoing project that will continue for a few weeks/months
Get involved in FSE work (blocks being added, themes being explored). There’s room for a lot of work there and not enough people at the moment. There is work being shared around the UX flows for template-parts, and navigation. Providing feedback there can help move things.
Task Coordination
@karmatosed deep down in global styles-land we have new mocks. I’ve also been giving feedback where can on some tickets, keeping that triage flowing.
Iterated on a proposal for the resolver that enables authors to target specifics parts the post (“all block paragraphs”, “cite within blockquotes”, etc): PR 20290
Bootstrapped a barebones global styles theme for demo purposes PR 22
Prepared a PR to explore a different isolation mechanism and how the process of migrating blocks to use CSS variables may look like PR 20273
For next week, I’m going to carry on that work and potentially resume the PR to connect the server data to the UI Controls PR by @itsjonq.
Getting caught up to start contributing again after being away for a few months while moving into a new house. You all move so fast! The last thing I had been working on was going through all the components to add them to Storybook.
Doesn’t look like there has been a ton of movement there, thoughts if that would still be worth my time, or should I look for somewhere else to start contributing (FSE?)
Working on documentation, dev notes, e2e tests for block variations API.
Introduced stable BlockSettingsMenuControls slot
Planning to help land changes for SlotFill refactor, want to finish Puppeteer upgrade, also want to work on optimizations for block editor build process in core.
Open Floor
Conflicts in Blocks with Vertical Aligned Columns
@leemon asks for a look at this Issue 19962, please. This bug affects many block plugins. I think it should be fixed in 5.4 @jorgefilipecosta This issue was already part of the must have board, unfortunately we did not fix it before the beta. If the fix is something very simple that we could include as a bug fix it would be good, but it is not something critical given that 5.3 already contains this bug.
Conflicts in Blocks with Vertical Aligned Columns
@isabel_brison General comment and feature proposal: gutenberg.run has been extremely useful for cross-platform testing, especially in an accessibility context. It would be great to have something similar for Storybook too! A few months ago, before gutenberg.run was working, I investigated using Tugboat for generating PR previews. It might be a good tool for a storybook preview, as it’s fairly simple to set up.
@gziolo There are two parts there, it feels like it’s time to document and promote gutenberg.run. It works great! @youknowriad For the second part, we discussed building Storybook into WPAdmin somehow and just use a single tool (gutenberg.run) for all. @gziolo We had integration for Storybook but there were some issues with using commercial hosting. I remember that discussion. It sounds great. Let’s open an issue for that if it doesn’t exist.
Nested Blocks in FSE
@BMO Does anyone have any updates on nested blocks and the impact on FSE? For example, being able to use semantic HTML in a template file? @jorgefilipecosta I think the solution is to provide head blocks and things like that @gziolo opened a PR 20218 that explores ways to make Group block flexible enough to cover this use case. @jorgefilipecosta making the group support several different tags may be a good solution.
@kjellr The current block-based themes spec doesn’t include anything about structural tags like <head>. That’s probably something we should consider separately.
@gziolo It raised the question how flexible it should be, should we allow any tag?, etc. I’m sure other questions will follow, like how to mark those groups as landmarks, whether to include visually hidden heading and similar accessibility related optimizations to start we should define the list of core supported semantic tags used for grouping and how they would look in the inserter. I would also like to discuss it with the accessibility team on how we can ensure the best possible experience
@BMO To ask what is probably an obvious question, is the focus or intent to prevent arbitrary HTML inside of template files? Because everything could/should be handled with a block? @youknowriad the answer is yes, because it needs to be editable as a block, though we have custom HTML block, custom classNames, etc. @BMO The group block solution looks interesting because it keeps these things nested.
Block-Based Theme Bi-Weekly Meeting
@kjellr Since we’re on the topic: every other week there’s a block-based themes meeting where we’re discussing these things too. The meeting is held in the themereview slack channel. For more information visit https://make.wordpress.org/themes/
In WordPress 5.4 a new package called @wordpress/keyboard-shortcuts has been introduced to centralize the registration/removal and documentation of the available keyboard shortcuts in the block editor screen.
Registering shortcuts
Registration of keyboard shortcuts should happen when first loading the screen/plugin. This can be achieved by calling the registerShortcut action.
wp.data.dispatch( 'core/keyboard-shortcuts' ).registerShortcut( {
// Shortcut name (identifier)
name: 'plugin/shortcut-name',
// Catergory (global, block or selection)
category: 'block',
// Description
description: 'Short description of your shortcut.',
// The key combination used to trigger the shortcut
// Could be just a single character or a character with
// a modifier.
keyCombination: {
modifier: 'primaryAlt',
character: 't',
},
// Some shortcuts can be triggered using several
// key combination, the aliases array is used to define
// the alternative combinations
aliases: [
{
modifier: 'primary',
character: 'i',
},
],
} );
Registering a shortcut automatically add it to the keyboard shortcuts help modal to ensure its discoverability.
Implementing the keyboard shortcut behavior
The @wordpress/keyboard-shortcuts package also provides the useShortcut React hook to define the behavior triggered by the keyboard shortcuts.
import { useShortcut } from '@wordpress/keyboard-shortcuts';
import { useCallback } from '@wordpress/element';
const MyComponent = () => {
useShortcut(
// Shortcut name
'plugin/shortcut-name',
// Shortcut callback
useCallback(
( event ) => {
// Do something when the keyboard
// shortcut is triggered
},
[]
)
);
}
Using this React hook instead of a custom implementation comes with a few advantages:
If the shortcut is unregistered by a third-party plugin, the callback is just ignored.
The shortcut key combination can be modified at runtime and the callback will still be called properly.
Removing existing shortcuts
Registered shortcuts can also be unregistered (and potentially replaced) by third-party plugins
WordPress 3.0 introduced wp_favicon_request() to avoid the performance hit that comes from serving a full 404 page on every favicon request. While that function works as intended, it doesn’t offer enough flexibility.
As of WordPress 5.4, theme and plugin authors can manage favicon requests much more flexibly, with the following logic:
If there is a Site Icon set in Customizer, redirect /favicon.ico requests to that icon.
Otherwise, use the WordPress logo as a default icon.
If a physical /favicon.ico file exists, do nothing and let the server handle the request.
This logic will only work if WordPress is installed in the root directory.
With these changes, /favicon.ico handling is now more consistent with /robots.txt requests.
New functions & hooks
WordPress 5.4 introduces a bunch of new functions and hooks for favicon handling:
is_favicon() conditional tag to complement is_robots().
do_favicon action to complement do_robots and use it in template loader. This hook will be fired when the template loader determines a favicon request.
do_favicon() function, hooked to the above action by default, to complement do_robots().
do_faviconico action to complement do_robotstxt, for plugins and themes to override the default behavior. This hook will be fired when displaying the favicon file.
With the above logic, do_favicon redirects to the Site Icon if it exists, or to WordPress logo as a default icon, using the following code:
function do_favicon() {
/**
* Fires when serving the favicon.ico file.
*
* @since 5.4.0
*/
do_action( 'do_faviconico' );
wp_redirect( get_site_icon_url( 32, admin_url( 'images/w-logo-blue.png' ) ) );
exit;
}
Themes and plugins developers can use do_faviconico action to override the default behavior.
Deprecations
wp_favicon_request() is now deprecated in favor of do_favicon().
For reference, see the related ticket on WordPress Core Trac: #47398
