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:
We used to exchange key project updates synchronously during the chat. However, many of the key Gutenberg projects sustain a regular cadence of updates on their tracking issues on Github.
This week we tried async updates. The attendees are encouraged to read the latest updates directly from the following tracking issues at everyone’s leisure:
Gathering consensus on add margin support to group block. #37344 PR. After a lot of thoughtful discussion I believe we have agreed this can be merged. Just needs final approval. Thanks again to everyone that participated in this discussion.
Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.
The general gist from a themers / my POV: The editor is taking a lot of liberties from us at the moment and makes things harder than they need to be. (And there are a lot of thing breaking by classes suddenly disappearing.)
@tomaz I really like this idea, one thing that I’ve learned in the past is that this requires some strictness as to language/vocabulary and breadth of what can/should be state, and what are the rules behind extending it, how to extend it at core level and how to make it available at local/theme level.
A great way to contribute to Core is writing summary posts for the developers chat. If you would like to help, please sign up for 23 February and 2 March 2022 in the comments.
Planning for WordPress release 6.0 has started. There are open roles on the 6.0 team (Editor Tech, Triage Lead, Test Lead, Accessibility Lead), and other volunteers needed so please comment on the post for those with interest/availability. More details on the roadmap for 6.0.
@costdev raised several areas for 6.0: Requests 2.0, Core Upgrader, Handling filenames in case-(in)sensitive filesystems, a preloader for resources needed during Core upgrades, temporary backup and rollback in the event of plugin update failures, plugin dependencies, test suite improvements. Make posts will promote further discussion and consensus.
The team publishes an agenda the day before the weekly dev chat. That gives you time to suggest additional own items or links by just leaving a comment. If you would like to help write the dev chat summary for a future meeting, contact the Core Team Reps @marybaum and @audrasjb.
“What’s new in Gutenberg…” posts (labeled with the #gutenberg-newtag) are posted following every Gutenberg release on a biweekly basis, discovering new features included in each release. As a reminder, here’s an overview of different ways to keep up with Gutenberg and the Full Site Editing project.
Text, Background, and Link colors can now be expanded and collapsed in different contexts. This improves the color editing experience and unifies the controls with other design tools. In addition, core blocks have been audited and their default color options have been updated accordingly.
New Post Author Biography and Read More blocks
Two new blocks have been included in this release. The Post Author Biography block is part of a bigger effort to split out the existing Post Author block into its separate components.
The Read More block provides a simple way to link to a single page or post within the Query block.
Keeping styles when transforming blocks
Block transforms keep improving upon each release. Starting in Gutenberg 12.6, some styles like color and font size are maintained when transforming between blocks.
Moreover, this release adds new block transforms, such as Tag Cloud to Categories, Calendar to Archives, Paragraph to Code, and Group to Row variation, as shown below.
Error boundary for plugin exceptions
Thanks to the new error boundary for plugins, the editor is now more robust against plugin issues. Starting in Gutenberg 12.6, plugin errors are displayed at the top of the editor to let users know which specific plugins are causing issue. This minimizes the potential impact of malfunctioning plugins when editing.
Iterative polishing of the loading states
Streamlining a blocks’ loading state has been a part of previous releases. For example in Gutenberg 12.3 the loading state of the Embed block was reduced to a spinner. With the latest improvements, Gutenberg 12.6 goes one step further and polishes the Spinner component to refine the experience.
Kudos to the first-time contributors that joined during the last release cycle: @JeffMatsonPagely, @angelistudio, and @sunyatasattva! If you are interested in contributing but do not know where to start, join the Core Editor weekly meetings on Wednesdays at 14:00 UTC in #core-editor focused on all things Gutenberg.
Update kotlin version for react-native Android projects to 1.5.32. (37970)
ESLint Plugin: Add flanking whitespace and hyphenated range rules. (38225)
Avoid first time contributor workflows for bots. (38393)
WP Env: Fix infinite redirection with custom site URL. (38352)
Performance Benchmark
The following benchmark compares performance for a particularly sizeable post over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.
As this is a minor RC release, select the Point Release channel and the Nightlies stream. This is the latest build including the RC and potentially any subsequent commits in trunk.
PR36186 – Spacer: add custom units for height and width
PR30873 – Focus save button when entities save states panel is opened
What’s next?
The dev-reviewed workflow (double committer sign-off) is now in effect when making changes to the 5.9 branch.
As per the proposedWordPress 5.9.1 schedule, the final release is expected on Tuesday, February 22, 2022. Please note that this date can change depending on possible issues after RC1 is released. Coordination will happen in the WordPress.orgSlack#5-9-release-leads channel.
A special thanks to everyone who helped test, raised issues, and helped to fix tickets. With this release candidate, testing continues, so please help test!
WordPress 6.0 will be the second major release of 2022. Following WordPress 5.9 Joséphine, 6.0 will aim to refine and iterate on the customization tools introduced earlier this year. In preparation, this post includes target dates, features, and squads.
This release will follow the same cadence as 5.9, with a long alpha and short beta periods before the release candidate phase.
Proposed WordPress 6.0 Schedule
Milestone
Date
Alpha (trunk open for 6.0 release)
January 4, 2022
Feature freeze/Bug Fixes
March 29, 2022
Beta 1
April 12, 2022
Beta 2
April 19, 2022
Beta 3
April 26, 2022
Release Candidate 1
May 3, 2022
Release Candidate 2
May 10, 2022
Release Candidate 3
May 17, 2022
Dry Run
May 23, 2022
WordPress 6.0 General release
May 24, 2022
Proposed WordPress 6.0 Scope
Take a look at the 6.0 preliminary roadmap, which includes Editor refinement, Pattern expansion, Navigation Block refinement, block exploration, and design tooling.
All release decisions will ultimately be this release teams’ to make and communicate while gathering input from the community.
How To Help!
If you are interested in being a part of 6.0’s release squad, please show your interest in the comments below. In particular, open roles that need volunteer support include:
As of the publish date of this post, 21 Trac tickets have already been fixed and backported to the 5.9 branch to be included in 5.9.1, and 3 more have already been fixed and are waiting for proper backport. 18 additional open tickets are currently in the 5.9.1 milestone for consideration.
During the 5.9 release, a new, #5-9-release-leads channel was created in Slack for the release squad to have all 5.9 related conversations. Because the 5.9.x releases are part of 5.9 by extension, all coordination and conversation related to the 5.9.x releases will also be held here before the channel is archived when WordPress 6.0 is released.
Could you help craft dev chat summaries in the next few weeks? Let the team know in the comments section. There is a volunteer for this week! Available slots coming up: 23 February and 2 March 2022.
The next major is 6.0. It’s still in alpha, so now is the perfect time to be working on your favorite enhancement or new feature.
The next minor is 5.9.1, and it’s going to be robust—and soon! Come find out all the details.
5. Open Floor
Post your suggested topic for discussion in dev chat in the comments. If you’re a component maintainer with a blocker, or you want some extra views on a ticket, add the items into the chat.
Any other items for the agenda
If you have any other items you would like to suggest for this week’s agenda, please add them in the comments. Thanks!
@flixos90: Would be valuable to research how these plugins store image information
@adamsilverstein: Also want to look at image storage; noticed that most at least support .htaccess rewriting in addition to changing HTML markup, but we can’t really do that in core
@mikeschroder is continuing work on an automated approach to testing, building on this work from Malte Ubl, which was recently MIT licensed so we can use it
@flixos90: Okay to work on these issues, but wary of adding more teams with dedicated time in this meeting. The teams were cerated based on voting and database didn’t make the cut. Issues like this can be brought up in Open Floor.
@sergiomdgomes: There was some discussion around embeds and how we could avoid the performance impact some of the larger ones, like YouTube, through façades or other approaches in the context of blocks; welcome thoughts and feedback
@flixos90: @sergiomdgomes also reviewed core theme PRs to eliminate jQuery from the front-end of the three remaining themes that use it, which could improve performance. All are using jQuery for simple things that can be done with vanilla JS. PRs are here for review: Twenty Fifteen, Twenty Twelve, and Twenty Sixteen.
@flixos90: Need to make a decision for Prepare initial release #133 on whether we’re okay shipping the WebP module in its current version where it no longer generates JPEG images, or whether we only want to ship it once it generates both JPEG and WebP images as intended. Vote here and leave a comment on why you think we should/should not release as-is.
@wp-source: Feel a lack of alignment on the scope of the plugin. Is it the plugin’s role to measure things like other tools already do?
@flixos90: Don’t think we should build measurement tools ourselves where we can already use existing ones. Measurement is a bit decoupled from the plugin, but if there’s a certain measurement feature that makes sense in plugin form, it could definitely go into the plugin. A lot of features may be built in other forms though, e.g. CI workflow, Docker images, etc.
@kirtan95: Should we use husky to run phpcs/phpcbf on post commit hook?
You must be logged in to post a comment.