Announcements

• WordPress 6.6 RC1 was released on June 25. We are now in a hard string freeze. Note that the dev-feedback and dev-reviewed workflow is required prior to committing to the 6.6 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". (handbook reference).
• WordPress 6.5.5, a security release, was shipped on June 24.
• Gutenberg 18.6.1 was released on June 25.

Great work getting all of these milestones done this week 

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. The WordPress 6.6 RC2 release is scheduled for next Tuesday, July 2. Please review this post for an update about the 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). Phase.

@meher brought up a discussion from the #6-6-release-leads channel about the string freeze in the release candidate stage. We discussed when the soft string freeze should happen and if it should exist, when the hard string should happen, how these two different freezes are different and if there are any exceptions.

@audrasjb highlighted the glossary items:

Hard freeze:
See String freeze. A hard string freeze or a hard freeze is announced when all the strings of the upcoming release are frozen including the strings of the About page. A hard freeze is the final string freeze before a release.

Soft freeze
See String freeze. A soft string freeze or “soft freeze” is announced when all the strings of an upcoming WordPress release are frozen, except for the strings of the About page.

@desrosj suggested we decide on the course of action for this release (6.6) and then do the research suggested here to adjust the practice going forward.

@audrasjb also found an example of a string change after the hard string freeze here.

@joemcgill summarised the next steps as follows:

• We’re currently operating in a Hard Freeze for 6.6
• @audrasjb is going to check with Polyglots to see if we can extend that date to 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). 3
• If we really do need Hard Freeze to start at RC1, we will update our docs for future releases

We’ll aim to have an update and share by next week’s Dev Chat.

Next maintenance release

No maintenance releases are currently being planned. However, we discussed follow-up tickets that were opened following the 6.5.5 release.

@audrasjb noted:

The most annoying post-6.5.5 ticketticket Created for both bug reports and feature development on the bug tracker. was #61488.
It was fixed in 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. and is waiting for potential backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. to branch 6.5. Question is: do we need a 6.5.6 for this?

Discussion

The main discussion was around 6.6 this week, so we moved straight onto the Open Floor section.

Open Floor

@grantmkin asked if we could discuss this issue to allow themes to side-load single block plugins, which could help seamlessly open up more creativity and options baked into 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. themes:

As I’ve been looking into the idea of canonical block plugins, one point of feedback I’ve received from theme designers is a desire to use such blocks in theme templates and patterns. One example shared was the desire for a tabs block to use in a product page template. If you’re releasing the theme for general use (rather than it being specific to an individual site) you’re currently limited to using coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks. And naturally, we’re conservative about adding new blocks to core. So I’m curious about possibilities for making more blocks available for use in themes and patterns.

There were several comments and questions raised, including:

• Sounds a lot like 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 for theme. – @afragen
• So not just starter content for themes, but starter blocks?  Interesting, seems pretty reasonable desire for themes. – @jeffpaul
• I wonder what a fallback would look like if a block was no longer available in the repo as well? Would it just no longer show, or would there be a way for the external block to fall back to core blocks? – @joemcgill
• In principle the idea of blocks like this is good because keeps them outside theme. – @karmatosed

@poena highlighted if the plugin that has that block is not installed, the user will be prompted to install it. If they don’t install it, they can keep the block as is, or delete it. So what is the problem we’re trying to solve with side-loading single block plugins?

@poena also noted that themes in the wordpress.org theme directory are not allowed to require plugins. That does not mean that those themes are not allowed to recommend and use block plugins.

@joemcgill encouraged folks to keep the convo going in the GH issue.

@mmaattiiaass also raised a discussion about the WordPress Importer project:

I would like to discuss the current state of WordPress-importer project. I think it’s an important piece for production sites, and it seems to be unattended.
Example: the font assets can not be imported automatically because that functionality wasn’t shipped to the users. There’s a PR adding that functionality that has been sleeping for months without any review despite being flagged as a blockerblocker A bug which is so severe that it blocks a release. for the font library in the WordPress 6.5 release.