Summary, Dev Chat, May 29, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @mikachan. 🔗 Agenda post.

Announcements

  • The scheduled date for WordPress 6.6 Beta 1 is June 4. From this point on, we will focus on testing and fixing bugs discovered during betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. testing. Begin writing Dev Notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. and the About page.
  • GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 18.4 was released on May 22. Read more about what was included in this release here.

Forthcoming Releases

Next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.6

We are currently in the WordPress 6.6 release cycle. See the Roadmap Post for details about what is planned for this release. Gutenberg 18.5 RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). is scheduled for May 31, which is the final RC before WordPress 6.6 Beta 1. It will include these issues and PRs.

Next maintenance release: 6.5.4

@jorbin has confirmed that there will be a 6.5.4 release scheduled for June 5, to accommodate #61269. An RC is scheduled for May 30.

@hellofromtonya shared that an alternate approach to #61269 is being considered for 6.5.4 and requested more feedback:

This could have an impact on the planned RC schedule for 6.5.4 depending on consensus on what approach to ship.

Discussion

With the Beta 1 deadline quickly approaching, we used the discussion time to check in on priority items for this release. Please review the list of Editor Updates from this week’s agenda for a list of updates of several key features related to this release.

@fabiankaegy has flagged that there are a number of commits that still need to be synced from the Gutenberg repo as part of this tracking issue. He also is tracking related PRs in this table on the WP 6.6 Editor Tasks board. Support from folks to review and commit these PRs is appreciated as we approach the 6.6 beta 1 deadline.

@joemcgill asked if the Release Squad needed any support to be ready for the 6.6 Beta 1 release next week.

@meher shared that all teams have reported a 🟢 status in the last check-in. Waiting for the Design and Performance to add their status. The documentation team has got help from folks.

Currently trying to decide whether the time to start Beta 1 should be 14:00 UTC or 16:00 UTC. Conversation about this continued after the meeting in the #6-6-release-squad channel.

Open Floor

Nothing was raised during Open Floor this week

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.

Props to @mikachan for proofreading.

#6-6, #core, #dev-chat, #summary

Summary, Dev Chat, May 22, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill. 🔗 Agenda post.

Announcements

  • The scheduled date for WordPress 6.6 Beta 1 is June 4, which is less than 2 weeks away. From this point on, we will focus on testing and fixing bugs discovered during betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. testing. Begin writing Dev Notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. and the About page.
  • @ellatrix recently announced that the last GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ release to go into WP 6.6 will have an RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). next Friday, May 31.

Forthcoming Releases

Our next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. is WordPress 6.6. See the Roadmap Post for details about what is planned. Also, see the Bug Scrub post for more details on when the 6.6 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs are happening.

@jorbin requested that we discuss the potential of doing a 6.5.4 release to accommodate #61269, and noted:

@hellofromtonya, @costdev and myself have been working through some options to help solve some issues that cropped up from pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party dependencies and are proposing #61269 as a solution that we would like to get in the hands of users as soon as possible.

Our suggestion is that we do a very small focused 6.5.4 on 5 June with an RC on 30 May. I am not currently aware of any other issues but would be open to including other fixes. I know it’s not much time for feedback, but am open to it as far as the schedule goes and also open to other tickets folks want to raise for inclusion.

The feedback that would be most helpful:

  • Testing and review of the proposed patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.
  • feedback on the schedule,
  • proposal of additional issues that should be considered for the release if any

@jorbin also highlighted that we will need someone with MC access, someone with a metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. sandbox, someone who can create a helphub page. Please reach out if you can help with any of these tasks.

The next GB release, Gutenberg 18.4, is going out soon and includes these issues. As mentioned during the announcements section of this chat, that means the following GB release (18.5) will be the last one planned to be included in WP 6.6. Now’s a very important time to be testing and reviewing PRs that are being synced from that repo to trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision..

Discussion

Ahead of the meeting, @annezazu highlighted the following updates on features for 6.6 – please help review and provide feedback as you can!

  • About a 10 minute long video demo of zoomed out view and where things stand, including current challenges with adding it to the pattern insertion experience. As it stands today, it looks like the zoomed out experience to build with patterns won’t be ready but will be an experiment in the plugin.
  • Block bindings latest update including a run down of merged PRs, risks for the release, and next steps. As it stands today, it looks like having the functionality to allow editing of custom fields when connected to blocks will likely not be ready for 6.6.
  • Section styling has a new discussion around CSS specificity which is necessary to resolve for the feature to land. There is potential breakage that might happen with the zero specificity styles and an alternative plan presented to preserve backwards compatibility.

@fabiankaegy and @colorful-tones have been doing great work triaging the WP 6.6 Editor Tasks board as well.

@vcanales mentioned the following issues in the WordPress 6.6 Editor Tasks board that are up for grabs for developers:

Open Floor

@dmsnell mentioned the HTML API: we’re getting nervously close to the deadline but still on task for our two main updates:

  • adding a spec-compliant text decoder
  • refactoring the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Processor so that it always presents a normalized “perfect” view of the HTML it’s parsing

@dmsnell mentioned that the best way to support this project is to review the work or share thoughts about how it’s all structured. The WP_Token_Map (Core-60324) is the biggest general thing in view and everyone is invited to share input on it or on the dev note I’ve prepared.

@dmsnell also raised two other tickets:

  • #61009 allows storing the proposed “Bits” syntax, making it possible for experimentation inside Gutenberg.
  • #61052 allows storing custom data attributes containing dashes, which is what the Interactivity APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. relies on.

The first one opens up the ability for Gutenberg to start experimenting with Bits, which are “Shortcodes, 2.0”, or dynamic tokens for externally-sourced data. This could use security review and scrutiny but is quite small in scope. The idea is that these can appear with a name and attributes which denote that something will replace it when rendered, but where Blocks are big, Bits are small, for example:

<//wp:post-meta key="isbn">

The main discussion around this is here.

The second ticketticket Created for both bug reports and feature development on the bug tracker. is about aligning kses with the needs of the Interactivity API. There is more information in this ticket. It would also be helpful to have more eyes and scrutiny on the way that this has been implemented.

For more information about both of these tickets, please read @dmsnell‘s messages during the dev chat from here.

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.

Props to @joemcgill for proofreading.

#6-6, #core, #dev-chat, #summary

Bug Scrub Schedule for WordPress 6.6

Following sessions are dedicated to move things forward and be ready in time according to 6.6 Release Schedule.

Everyone is welcome to join not only to triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. tickets but also to look for tickets you can contribute by creating patches, making code review and testing.

Things to keep in mind:

  • All features and enhancements should be in the Trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. before BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 and most bugs and all strings need to be there before RC1.
  • If you are working on a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., plan your contribution to have enough time for other contributors to make suggestions, review and test.

Alpha Bug Scrubs

Focus: features, enhancements and then bugs with priority on tickets that are closer to resolution

Beta Bug Scrubs

Focus: rest of the bugs plus reported regressions

Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). Bug Scrubs (if needed)

Focus: issues reported from the previous RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)..

  • TBD

Check this schedule often, as it will change to reflect the latest information.

Regular component scrubs and triage sessions

For your reference, here are some of the recurring sessions:

Have a regular component scrub or triage session?
PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” @nhrrob or @oglekler on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. to have it added to this page.

You can start your own triage sessions

  • Decide what you want to work on

6.6 triage session are our priority and moving forward tickets which already are scheduled for the release is most needed task. If you want to lead some of them, they can be added on this schedule.

But if you are interested in particular component or user focus, for example to take care about RTL-tickets, this will be most welcome too.

Especially interested can be the session to scrub old tickets. We are continuously closing new tickets with the same topic in favor of existing ones and because these tickets are looking complicated just because they’re age not, so many contributors are eager to work on them, but there are actual treasures hidden among very difficult or tricky topics.

  • Ping @oglekler or@nhrrob on Slack with the day and time you’re considering, as well as the report or tickets you want to scrub. Note that scrubs are happening in the main coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. channel and cannot clash with other meetings in this channel.

Useful reports and information

  • Report 5 provides a list of all open 6.6 tickets:
    • Use this list to focus on highest priority tickets first.
    • Use this list to focus on tickets that haven’t received love in a while.
  • Report 6 provides a list of open 6.6 tickets ordered by workflow.

Need a refresher on bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs? Checkout Leading Bug Scrubs in the core handbook.

#6-6, #bug-scrub, #core

Summary, Dev Chat, May 15, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @annezazu. 🔗 Agenda post.

Announcements

A reminder that the WordPress 6.6 roadmap has been published. Please also read and leave feedback on the Server to client data sharing for Script Modules proposal. Feel free to leave feedback either during Dev Chat or on the proposal post.

Forthcoming Releases

We’re currently in the WordPress 6.6 release cycle. You can find out more about the release squad in this post.

@annezazu noted that after a discussion in the public #6-6-release-leads channel, there is an update underway for the remaining roles yet to be filled. This has now been posted here.

For any folks who want to learn more about the release and help contribute back, I want to call attention to this post on Early opportunities to Test WordPress 6.6. Help the release and learn about it at the same time!

Discussion

Release Squad: A lengthy discussion ensued about the fact that 3 weeks from BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 that the full release squad has not been filled. There were questions about why this release has been so hard to fill and what we could do to improve this in the future. Some questioned the size of the release squad making it difficult to fill and others questioned the length of the cycle. Suggestions were made to try to recruit a release squad earlier in the cycle, or even at the end of the previous cycle.

Note: Since the meeting, the WordPress 6.6 release squad is ready.

Canonical blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. plugins proposal: There is an initial issue and discussion here, and a follow-up Gutenberg PR is currently in progress to create a time to read block. Have folks had a chance to catch up here? Any questions or concerns?

  • @jeffpaul questioned what problem this would solve compared with either shipping these blocks in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. or allow them to be maintained as community plugins.
  • @jorbin expressed support for the idea, but identified that there were some questions that need to be answered in addition to what @grantmkin shared in this GitHub comment.
  • @annezazu shared that the difference is useful in that some blocks haven’t been a great fit for Core, for a variety of reasons. This separation allows the base experience to remain the same while offering strong, supported blocks provided by Core that folks can add on.
  • This was a lengthy discussion. Everyone is encouraged to provide feedback on the related issue.

Proposal: Server to client data sharing for Script Modules: This proposal is still looking for feedback.

Open Floor

@kkmuffme requested guidance on several tickets that have stalled, that he is hoping will get picked up in time for the 6.6 release. Following the meeting, @jeffpaul scrubbed the list and pinged relevant core developers who might be able to review and provide feedback.

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.

Props to @mikachan for proofreading.

#6-6, #core, #dev-chat, #summary

WordPress 6.6 release squad ready

This post is a follow-up to the WordPress 6.6 call for volunteers update.

I’m glad to announce the WordPress 6.6 release squad is ready and the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and Documentation lead roles have been filled:

Big thanks to everybody who volunteered to the release squad or to mentor and support!


Thanks to @chanthaboune for reviewing this post.

#6-6 #planning

Summary, Dev Chat, May 8, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill. 🔗 Agenda post.

Announcements

The WordPress 6.6 roadmap has been published.

WordPress 6.5.3 was released on Tuesday, May 7. This minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. features 12 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and 9 bug fixes for the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. You can review a summary of the maintenance updates in this release by reading the Release Candidate announcement.

Gutenberg 18.3 was released on Wednesday, May 8. The release highlights include a full page client-side navigation experiment, negative values for margin controls, and adding a publish flow to the editor.

Forthcoming Releases

We are currently in the WordPress 6.6 release cycle and 4 weeks away from BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1. The latest update on the release squad is detailed in this post and there are a few TBD roles for Core triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and Docs leads. During the meeting, @OGlekler volunteered to be Core Triage Lead for 6.6. @priethor also followed up with a note to say:

  • Would the Core Triage role benefit from a second lead?
  • The Docs lead role is nearly ready too.

@jorbin confirmed that 6.5.3 came out on May 7. Thank you to everyone who helped. We now need to consider whether we should plan a 6.5.4. As of now, there is one potential regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. that is being investigated, so @jorbin suggested that we give it one to two weeks before making a decision. The 6.5.4 milestone has already been added in tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

@annezazu noted that the only other feedback is around this: https://github.com/WordPress/gutenberg/issues/59511: There’s been some feedback from an enterprise client as they can no longer change titles easily. The problem is there’s not an intermediate solution in the works and it will be resolved by 6.6 when the site editor pattern experience comes to classic themes. This will be discussed further in #6-5-release-leads.

Discussion

Here are a couple of follow-ups from previous meetings:

  • New slack channels: #core-interactivity-api was created to help folks working there better organize and collaborate.
  • GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ commits: as a way to bring additional visibility to changes committed in the Gutenberg repo, we’ve started an experiment to show commits to the trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". (PR merges) in the #core channel.

We dedicated a lot of discussion time to the 6.6 roadmap and any updates about the major efforts listed on the Roadmap.

@afragen gave an update about Rollback Auto-Update: there have been zero reported issues with the PR. We’re currently just looking at making some of the comments a bit more descriptive. Hopefully Rollback Auto-Update will be committed in the next day or so.

@johnbillion raised #61173: if anyone wants to help with that workflow that would be great.

Open Floor

@azaozz requested for “more eyes” and reviews on https://github.com/WordPress/wordpress-develop/pull/6407#issuecomment-2101275000. This is a PR that properly fixes the infinite loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. as reported on #60652 (the current patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. just hides it, that PR removes the possibility for a loop to happen). It also fixes the possibility for a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to completely remove the new font_dir filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. which is a pretty nasty thing to do and would break all other plugins that are using that filter.

@kkmuffme requested some final reviews on the following PRs:

@grantmkin also noted: @vcanales and I have started exploring “canonical block plugins,” an idea to have more community developed blocks that are shipped as stand-alone block plugins, for blocks that aren’t a fit in the default block library shipped with Gutenberg/WordPress. The primary issue is at https://github.com/WordPress/gutenberg/issues/58773, in case you’d like to learn more about, follow, discuss, or contribute to the effort. There will likely be a follow-up on make/core to get more feedback.

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.

Props to @joemcgill for proofreading.

#6-6, #core, #dev-chat, #summary

Merge Proposal: Preferred Languages

Almost 8 years ago the Preferred Languages feature project was kicked off in response to a feature requestfeature request A feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. in #28197. Right now it is probably the oldest active feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.. Over time there were numerous updates, bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes, and even a complete refactor. Preferred Languages was always built and maintained with the goal in mind to merge it into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. one day. Now the time is finally right to do so.

Purpose & Goals

As a quick reminder, Preferred Languages replaces the existing languages dropdown with a supercharged version that lets you select multiple preferred languages. WordPress then tries to load the translations for the first language that’s available, falling back to the next language in your list otherwise. Without this, WordPress would just fall back to English (US) in such cases, which is not a great experience. Such a UIUI User interface is a pretty standard feature that can be seen for example also in operating system and browser settings.

Preferred Languages UI, showing the list of selected languages on the settings page.
Example of the Preferred Languages UI on the settings page

Note: Preferred Languages works for both the site language (can be set at Settings -> General) and the user language (can be set in the profile).

Project Background

You may wonder why it took such a long time. Since the project’s inception, a lot has changed in WordPress. For example, GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ happened. That’s why Preferred Languages saw a complete rewrite using the same ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. components that also power the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. With Gutenberg we also saw the introduction of JavaScript localization, which required further iterations to Preferred Languages. Then there was a need for merging incomplete translations, reducing the chances that you see missing strings in English. However, merging translations was very bad for performance, as it involves loading lots of translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. files. In WordPress 6.5 we finally completely replaced the localization library with a more performant solution that natively supports loading multiple files at once. So this last remaining blockerblocker A bug which is so severe that it blocks a release. is now finally resolved!

Internationalization and localization is a core part of WordPress and relevant for more than half of all users. That’s why this functionality belongs natively into WordPress core and not in a (canonical) plugin. Merging Preferred Languages into core would allow the fallback logic to run much closer to where translation loading happens, reducing the risk for bugs and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party incompatibilities. Plus, the UI impact is minimal, as it simply expands an existing language dropdown with additional features.

Implementation Details

The UI is built using TypeScript and React and the @wordpress/* npm packages also used for Gutenberg. This makes for a consistent look & feel and will make it easy to integrate it into any revamped WordPress adminadmin (and super admin) UI. The back end parts were developed in such a way that merging them into core eventually is as straightforward as possible, so a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. can be developed relatively quickly.

Preferred Languages has been tested in production websites over numerous years by thousands of users. It works in all major browsers supported by WordPress, follows accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) best practices, and gracefully falls back to the old single language dropdown if JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. is disabled.

Contributors and Feedback

While I (@swissspidy) have been the lead developer of the plugin, valuable input and contributions have come from others in the community.

This is a proposal and is subject to revision based on your feedback. If you haven’t already tried out the plugin, please download and install it from WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ or the comfort of your WordPress admin. You can review the current code and leave feedback at the project’s GitHub repository or in #core-i18n on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

All feedback will be collected over the next couple of weeks. After that, the received feedback will be discussed and next steps determined. The goal is to work on and land a patch quickly to ensure that the feature gets plenty of testing in WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision..

Props to @ocean90 for reviewing this post.

#6-6, #feature-plugins, #feature-projects, #i18n, #merge-proposals, #polyglots, #preferred-languages

Roadmap to 6.6

WordPress 6.6 is set to be released on July 16, 2024. With a slightly shorter cycle, this release heavily builds on the foundation of the last with some new items, like section styles and overrides in synced patterns, and loads of enhancements to features that landed in the last few releases, including the Font Library and Interactivity APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. Data Views, the first taste of the admin redesign work introduced in 6.5, continues to evolve with new layout options, a combined template part and pattern experience, and more readily accessible management sections. Finally, design tools take center stage with everything from grid layout support to section styles to more power baked into style variations out of the box. 

As always, what’s shared here is being actively pursued, but doesn’t necessarily mean each will make it into the final release of WordPress 6.6.

For a more detailed look at the work related to the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, please refer to the 6.6 board and review the currently open Iteration issues. After a recent organization effort, Iteration issues are meant to reflect active work that’s been scoped down for a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. To get a sense of some of what’s being worked on both for this release and beyond, check out the demos shared in a recent hallway hangout.

Foundational experience

Advancing the new Data Views in the Site Editor

Building on an initial launch in 6.5, the new views in the Site Editor continue to be refined and advanced. This includes work to bring the various management pages forward (manage all templates, manage all template parts, manage all pages) so those options are immediately seen when visiting the respective sections, reducing the number of steps to access important information. For pages, a new side by side layout will be introduced so one can see both a list of all pages and a preview of the currently selected page. For patterns, template part management will be removed and integrated into the current overall patterns section. Interspersed within all of these larger changes are smaller enhancements in functionality and feel. 

Manage template screen showcasing the side by side layout with navigation on the far left, a list of templates in the middle, and a larger preview window on the right showing the current template.

Follow this tracking issue for more information. 

Zoom out to compose with patterns

A few different initiatives are coming together to allow one to focus on building with patterns rather than granular block editing, including advancing contentOnly editing and zoomed out view. Key features planned include:

  • A zoomed out experience in the editor when inserting patterns to facilitate high level overview of the site.
  • Ability to shuffle top level patterns within a template in order to quickly explore alternative patterns.
  • Ability to manipulate patterns in the template via moving, deleting, etc while zoomed out. 
  • Improvements to UXUX User experience for dragging patterns (e.g. vertical displacement).

Taken together, this work aims to offer a first step towards a new way to interact with and build with patterns. Some questions remain including whether zooming out will be invoked in certain situations, like the patterns tab of the Inserter, or if it’s something that could be toggle on/off as one wants. 

Pattern inserter open to Banner patterns with the content of the site zoomed out, showing more of the template that the pattern is going to be added to.

Follow this iteration issue for more information. 

View inherited style values

Knowing where a block’s style comes from is key to knowing where a change might need to be made. For 6.6, work is underway to show locally the value that a block inherits globally, when applicable. This means that, for example, if you set a paragraph to always have blue text in Styles, every paragraph you added will show blue text and the block settings will show the blue color as the chosen text color. This is in contrast to today’s confusing experience, where it shows a circle with a line through it, to indicate that no local color has been set despite the block inheriting it globally. 

Follow this issue for more information. 

Unifying editor experiences, including publish flow

This is both a technical and design effort, consolidating shared code and creating a single, coherent flow across the post and site editors for common tasks. The more noticeable and big pieces will be seen in a unified publish flow and a new singular “summary” inspector panel, which will also be reused within the site editor when you are bulk editing. 

Follow this iteration issue for aligning features and this tracking issue for the inspector controls for more information. 

Design tools

Mix and match typography and color palettes from all styles variations 

Style variations allow you to change the look and feel of your site, all while using the same theme. To build on the design possibilities of a block theme with style variations, 6.6 aims to add the ability to mix and match the color and typography styles of each individual style variations. This means the eight community created style variations baked into the Twenty Twenty-Four theme turns into 48 styling combinations, thanks to the six typography presets and eight color presets available. Add in more typography options thanks to the Font Library and the optionality available is immense, alongside all of the granular tinkering you want to do. This evolution in style variation possibilities will work out of the box with all block themes with style variations with no additional opting in or adjustments on the theme author’s end. 

Follow this iteration issue for more information. 

Syncing specific blocks and attributes of patterns

Building upon synced patterns, overrides in synced patterns would allow users to ensure a synced layout and style across patterns while allowing each instance of the pattern to have customized content. This allows for consistency in design across different pieces of content. For instance, consider a testimonial pattern in a grid. With the enhanced feature, someone can insert this testimonial pattern into multiple posts, ensuring that the layout and styling components, such as the overall design of the recipe card, remain consistent across instances. Meanwhile, the content, such as Name, Image, and Role, would be local to each instance allowing for individual customization. Additionally, folks would then be able to revisit and modify the design of the overall testimonial pattern without affecting the content in existing instances. To get a sense of the current work happening here, check out the “overrides in synced patterns” demo from a recent hallway hangout below:

Follow this iteration issue for more information 

Expanding block style variations for more styling options 

Through work to extend the block style variations mechanism, 6.6 is set to introduce the ability for theme authors to define style options for sections of multiple blocks, including inner blocks. With just a few clicks, folks using block themes that add this functionality could quickly change just a section of a page or template to predefined styles that an author provided, like a light or dark version of a section. This feature is coming together thanks to work to expand the block style variations API. There are a few ways folks are aiming to offer this functionality:

  • Programmatically via gutenberg_register_block_style
  • By standalone theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. partials within a theme’s /block-styles subdirectory
  • Via theme style variations defining block style variations under styles.blocks.variations.

To see a very early look at this work, check out the “Section Styles” demo from a recent hallway hangout.

Follow this iteration issue for more information. 

Improvements to Grid Layout

Grid is a new layout variation for the Group block that allows you to display the blocks within the group as a grid, offering new flexibility. There are two options for the Grid layout:

  • “Auto” generates the grid rows and columns automatically using a minimum width for each item. 
  • “Manual” allows specifying the exact number of columns.

Outside of expanding functionality, including trying to implement drag and drop resizing, work is also underway to improve using layout tooling in general to make it simpler and clearer to accomplish what you want.

Follow this tracking issue for more information and/or join the dedicated #feature-grid slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel. 

Refining the Font Library 

To build on its debut in 6.5, the Font Library will continue to see bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes and enhancements based on incoming feedback. This work will be less about adding new functionality and more about refining what’s landed. 

Follow this iteration issue for more information. 

Additional supports

A selection of smaller efforts come together to provide more design options directly in the editor:

Adoption pathways

Bringing the Site Editor experience for Pattern management to Classic Themes

Thanks to some internal code changes, the path is set to enable Classic Themes to have access to the new Patterns experience that the Site Editor provides. This will provide an upgraded, modern experience of managing and creating patterns.

Follow this iteration issue for more information. 

Continued performance improvements

This release cycle, a variety of initiatives are focused on improved loading times, especially template loading with improved caching of theme.json, block templates and computed styles as well as optimizing autoload options. Research and initial work to address potential improvements to the INP (Interaction to next pain) metric is also continuing in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and the Interactivity API. In addition, ongoing performance improvements for the editor for this release are being tracked in this iteration issue, including major improvements to template loading.

Outside of the above efforts, work continues to improve performance tooling, including our automated performance test actions running in both GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ and core. The current effort is focused on making the performance tests more consistent, robust and reliable and on providing an easy-to-use GitHub action developers can leverage to implement the performance tests in their own pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme.

API iterations

Various APIs recently introduced in the last few releases are all slated for continued upgrades.

Interactivity API

The Interactivity API provides a standard way to allow developers to add interactivity to the frontend of their blocks. After the release of the initial version of the Interactivity API in 6.5, this next round of work is focused solely on enhancing the developer experience with better test coverage and code quality, improved error reporting, debugging tools, and fixing reported bugs.

Follow this iteration issue for more information and/or join the dedicated #core-interactivity-api slack channel. 

Block HooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.

Introduced in WordPress 6.4 and iterated upon in 6.5, the Block Hooks API is an extensibility mechanism that allows you to dynamically insert blocks into block themes. At this stage of maturity, work is underway to help determine a proper UIUI User interface for hooked blocks and continued improvements to the developer experience. 

Follow this tracking issue for more information. 

HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API

Building on the initial launch in 6.2, work continues to evolve the HTML API with a focus on two aims for 6.6:

  • Complete and rely on a custom and spec-compliant encoder/decoder. 
  • Design how to communicate when an HTML document has retroactively changed, allow calling code to match on, stop at, and modify implicitly-created elements, including when elements are closed.

Follow this iteration issue for more information. 

Custom Fields & Block Bindings API

The Block Bindings API launched in 6.5 allows you to bind dynamic data to block attributes, solving many use cases for custom blocks and powering other features, like overrides in synced patterns. This next round of work is focused on allowing the editing of connected sources directly from the block. As showcased in a recent Hallway Hangout, users can update the value of a custom fieldCustom Field Custom Field, also referred to as post meta, is a feature in WordPress. It allows users to add additional information when writing a post, eg contributors’ names, auth. WordPress stores this information as metadata. Users can display this meta data by using template tags in their WordPress themes. by editing the paragraph connected to it. As part of that, the existing editor implementation is being refactored, and the editor APIs are being defined with the goal of “potentially” making them public for 6.6. Outside of the broader technical work, initial explorations are underway around a UI to create bindings, but it’s unlikely to land for 6.6.

Follow this iteration issue for more information.  

Dropping support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 7.0 and 7.1 

Support for PHP 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater. Read more in the Dropping Support for PHP 7.1 Make Core post

Add rollbacks to auto-updates

Since WordPress 6.3, when an administrator is manually updating plugins, the plugin will not be reactivated if the update causes a PHP fatal error. During an auto-update, this reactivation check does not occur and the next time the site runs users will see the white screen of death (WSOD). To further protect websites and increase confidence in automatic plugin updates, 6.6 aims to include the ability to perform rollbacks when fatal errors occur during attempted plugin auto-updates by default. To learn more, please review the merge proposal for this feature

Find something missing? Want to help?

If you have something you’re working on that you don’t see reflected in this post, please share a comment below so we can all be aware! If you’re reading this and want to help, a great place to start is by looking through each issue associated with each area or by diving into the Polish board where a curated set of issues are in place that anyone can jump in on.

Thank you to @adamsilverstein @joemcgill @fabiankaegy @get_dave @ellatrix for reviewing and contributing to this post!

#6-6, #release-roadmap

Summary, Dev Chat, May 1, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill. 🔗 Agenda post.

Announcements

The WordPress 6.5 retrospective survey is now closed. Thank you to everyone who responded! Expect a follow-up post with collected, anonymized results once @priethor@marybaum, and @akshayar have finished processing all of the feedback.

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 18.2 was released on April 24. Read about what’s new in this release.

The remaining Phase 3 related overview issues were created for folks to join Phase 3: Block LibraryPhase 3: WorkflowsPhase 3: Revisions, and Phase 3: Collaboration index. Thanks to everyone who worked on creating and updating these Phase 3 issues!

Forthcoming Releases

We’re in the 6.6 release cycle. @annezazu shared that the roadmap draft is well underway, and @ella has already created this tracking issue to coordinate PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher backports.

@fabiankaegy noted that it is worth calling out that there are still a few roles that are looking for volunteers. @priethor added: in particular, the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Lead role is the one with the most in need of volunteers. There are a few inexperienced volunteers for the docs lead role, but it would be great if somebody with experience in the role could participate, too. Please reach out to @priethor directly if you have any questions.

A quick update about the next maintenance release, WP 6.5.3. There are currently 3 open trac tickets and 1 Gutenberg ticket left to resolve. A Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). is planned for May 2 at 17:00 UTC, with a tentative release date planned for May 7. There is more information about this release in this post, including the bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub schedule and how you can get involved.

A quick reminder that our next Gutenberg release (18.3) is in progress and the Release Candidate is scheduled for May 2.

Discussion

We dedicated the discussion time to revisiting the conversation that was kicked off last week during our announcements related to recent #core-editor conversations about how we can improve how contributors follow along with editor updates and improve communication within the project.

To kick things off, @joemcgill shared some suggestions that @youknowriad posted on the agenda:

I know a lot of Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. follow core updates by following the commits that happen on the #core slack channel. I believe that we should be doing the same for editor commits. These commits are already shared on slack on #core-editor-commits channel. That would be IMO a great way for core contributors to keep up with what’s happening on the editor side and potentially interact (even on merged PRs like we do for closed tickets on tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.) without waiting for the code to reach Core through backports or anything.

I think we can also consider showing these commits directly in the #core channel in Slack like we do for Core commits because in the end, these are core commits too, they just happen on another repository. Today we have between 10 and 20 commits per day, I think that’s an acceptable number that won’t “flood” the channel that much and would bring more visibility.

We discussed that we could experiment with posting commit summaries to the #core channel for a short period of time, such as a few weeks, and evaluate how it works. We also discussed that the commits from Core provide more detailed summaries compared to the commits to trunk on the Gutenberg repo, so this is a potential improvement for the Gutenberg commits. @audrasjb noted the Core handbook link for Commit message best practices.

@joemcgill said that he will follow up on moving this forward this week.

@azaozz noted:

There was another concern in that discussion: many contributors that cannot contribute very regularly are missing when development starts for (major) new features. That results in not being able to start contributing to them in time, or not providing timely feedback, ideas, being able to test different approaches, etc.
One of the ideas how to fix this was to start announcing when new major features development starts in dev. chat (and in the summaries). Seems most/nearly all contributors follow make/core and that would benefit them.

@priethor noted that Dev chat time is not very EU-friendly, asking folks to announce features here can be a big ask depending on the project.

@joemcgill summarised that there are several things to unpack here, primarily:

  1. How can we make it easier for people to contribute to new features
  2. What is the right timing and method for communicating updates at key milestones for a feature (e.g., merges, etc.)

@hellofromtonya suggested: How about a Make/Core post with links to tickets or project board and/or the key labels for tracking?

Open Floor

@afragen gave an update on the Merge Proposal: Rollback Auto-Update, and noted that we haven’t received any issues with testing so @afragen believes that it’s going well and we’re on our way to commit in a week or so. Also, there are 6000+ active users of the feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.. Please read the proposal and test the feature plugin in the next week, ideally before the next dev chat.

#6-6, #dev-chat, #summary

Summary, Dev Chat, April 24, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @mikachan.
🔗 Agenda post

Announcements

An update for the 6.6 release squad has been posted, please note that the release squad is looking for one or two CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads to focus on triaging TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and a Documentation Lead with previous experience for the role.

Also, a reminder that the WordPress 6.5 retrospective post has been published, please fill in the survey if you would like to leave feedback or suggestions for improvements to the release process. The form and comments will be open until April 26th, 2024

There was also a recent discussion in the #core-editor channel around several topics linked to how we can improve how contributors follow along with editor updates and improve communication within the project. There were several potential actions discussed, including:

  • Create more high-level tracking issues that are not tied to a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope..
  • Create Slack channels for high-level features, such as navigation (#feature-website-navigation) and the grid blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. (#feature-grid).
  • Create teams on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ for high-level features to create an easy point-of-contact and discussion space for these features.

@annezazu called out that she did some recent work cleaning up the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repo, which should help with this, including getting high-level overview issues in place for all phase 3 items.

Tied to this, 6.6 is the start of having set iteration labeled issues that are targeted for the release and should make it easier to follow release-specific, in-progress work: https://github.com/WordPress/gutenberg/labels/%5BType%5D%20Iteration

@jorbin suggested a make/core post outlining more specifics about the intended process for the iteration issues, to make sure things stay up to date.

@mikachan believes that a summary post is being written to help summarize the next steps from the discussion that happened over in #core-editor.

@johnbillion and @priethor both expressed concerns about potential siloing if we experiment with adding more feature channels.

Forthcoming releases

Next major release: 6.6

We are currently in the WordPress 6.6 release cycle.

Next maintenance release: 6.5.3

There are currently 15 open tickets in the 6.5.3 release milestone. There is more information about this release in this post, including the bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub schedule and how you can get involved.

@jorbin gave the following update:

6.5.3 is still on target for 7 May. Scrubs have been moving things forward. There are a couple of at risk tickets so if you see something towards the bottom of https://core.trac.wordpress.org/tickets/minor/workflow, it would be good to jump in to help.

There are also a few tickets on GitHub so look towards the left there to see tickets you can help move forward https://github.com/orgs/WordPress/projects/186

Next Gutenberg release: 18.2

Gutenberg 18.2 is scheduled for April 24 and will include these issues. During the meeting, @colorful-tones asked for support with a problem encountered while publishing.

Discussion

@peterwilsoncc previously raised that we should consider syncing the editor packages earlier in the release cycle. Could this be attempted for 6.6? Slack reference.

  • This process is documented here, but @youknowriad warned that a lot of that work is also manual for the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher part and not something that doesn’t have a clear workflow.
  • @johnbillion noted a related issue, #60967, which could help with this process.
  • @joemcgill suggested that we put some focus on reducing friction of the PHP syncing during this release and will follow up with @youknowriad and tech leads @ellatrix, @vcanales, and @audrasjb about some next steps.

@afragen published the Merge Proposal for Rollback Auto-Update and asked for more testing and feedback in order to commit this early during the cycle.

Highlighted posts

The full list of posts from the last week in Core can be read on the agenda at this link.

Open floor

There was no time for the open floor section during this dev chat, but @drivingralle did mention a potential ticketticket Created for both bug reports and feature development on the bug tracker. for 6.6 on the agenda post:

Would be great if ticket #55184 could be included in 6.6.

Props to @mikachan for reviewing.

#6-6, #dev-chat, #summary