Dev Notes Tracking Issue for WordPress 6.0

[bph]

Description

For WordPress 6.0, a GitHub project is being used to track dev notes and their progress. You can find the dev notes project view here - https://github.com/orgs/WordPress/projects/28/views/1

Please share your notes here as comments or a link to a shared Google document. The WordPress 6.0 Documentation team (@zzap, @abhansnuk @aurooba and I, @bph) will be happy to assist in wording and scope.

If your note is ready to be posted on Make Blog and you have privileges, then go ahead and post it in draft, we can wrangle the reviews.

The dev notes should start latest with Beta 1, but you can certainly start now.
Deadline is before WP 6.0 RC (May 2nd, 2022) - You don't have to wait for the last minute to get it done, thought. 😘

⭐️ Handbook Page: Writing developer notes

Please leave a comment, also if you're unable to write a note for your PR or if you need assistance.

I'll start connecting with PR authors 1:1 to double-check availability, and see if I can unblock things.
👍 (saw it and Thank You! ) 🚀 (in review)

• Gallery block: Add css var to enable theme authors to set a default gallery gap #40008 @glendaviesnz
• Add color support to the quote block #39899 @youknowriad
• Add a box-sizing border-box to lists #39895 @youknowriad
• Block.json: Add ancestor prop to schema #39894 @DAreRodz
• Add raw attributes config for media entity #39512 @youknowriad
• Blocks: Remember raw source block for invalid blocks. #38923 @dmsnell
• Blocks: Deprecate isValidBlockContent #38794 @dmsnell
• Handle resolution errors in @wordpress/data #38669 @adamziel
• [core-data] Do not suppress errors in the getEntityRecord and getEntityRecords resolvers #39317 @adamziel
• Remove the div wrapper from the aligned image blocks #38657 @youknowriad
• Remove data-align divs for themes that support layout #38613 @youknowriad
• Remove APIs deprecated on WordPress 5.4 #38564 @youknowriad
• Introduce the customScripts property to allow templates to define additional scripts in package.json #38535 @ryanwelcher
• Adding the "env" script when --wp-env or wpEnv is present. #38530 @ryanwelcher
• Separator block: refactor to use color block supports #38428 @glendaviesnz
• [Pattern Directory]: Allow pattern registration from directory with theme.json #38323 @ntsekouras
• Gallery block: add gap support / block spacing #38164 @glendaviesnz
• [Global Styles]: Add REST API endpoint to fetch variations #38124 @ntsekouras
• Add the WP version in which some JS APIs will be removed #37854 @youknowriad
• LineHeightControl: Enhance interactions by migrating internals to NumberControl on Style options. #37160 @mirka
• Block Patterns: Automatically load headered files from a theme's /patterns directory #36751 @mcsf
• [create-block] Add npmDevDependencies as a template variable. #39723 @ryanwelcher
• Add: Option to pick a pattern on page creation. #40034 @jorgefilipecosta
• Add the stack block variation to the group block #39690 @jasmussen @youknowriad
• Wrap title of block in <ListView> in a span #39687 @getdave (could go into Miscellaneous "Little Gems" post )

Theme Export

• Theme Export: Add index.php and style.css #39173 @scruffian
• Theme Export: Export the whole theme #39202 @scruffian
• Theme Export: If the theme declares a version number then add a schema #39775 @scruffian
• Theme Export: Change the schema url #40106 @scruffian
• Theme Export: Remove default theme.json properties on export #39848 @scruffian
• Theme Export: Sort theme.json properties #39842 @scruffian
• Theme Export: Restore appearanceTools when exporting a theme #39840 @scruffian
• Theme Export: Use the theme name for the zip file #39471 @scruffian

Lock Settings

• Block Editor: Introduce the 'useBlockLock' hook #40210 @Mamaduka
• Block Editor: Add block lock setting #39566 @Mamaduka
• useBlockLock: Improve argument name and description #40220 @Mamaduka
• Template Parts: Hide 'Detach blocks' when locked #40000 @Mamaduka

---

** Updates 4/29/2022**
#39950 didn't not in WP6.0
#38780 experimental API (no documentation)
#38397 -> Field Guide: But Wait section.
#36811 (already in 5.9)
#38663 @oandregal (bug fix only)

Updates 4/14/2022
## WebFonts API - probably won't make it into 6.0 as it wasn't merge by Beta 1 (Feature Freeze) (discussion in release leads channel)

#36176 @gziolo @aristath - won't be in 6.0 (comment)

[adamziel]

DevNotes issue for WordPress 5.9 for inspiration and everyone's reference

[adamziel]

Here's a data module related dev note, if there are more data module dev notes, they could potentially be grouped together in a post.

Data Module

Support for Handling Resolution Errors

WordPress 6.0 no longer ignores the exceptions thrown by the resolvers.

In WordPress 5.9 and earlier, an exception thrown inside the resolver kept it in the resolving state forever. It never got marked as finished. In WordPress 6.0, the resolver state is set to error and the exception is re-thrown. This backwards compatibility-breaking change affects both resolvers from newly registered stores and the resolvers from the WordPress stores, e.g. the getEntityRecord resolver from the core store.

Example:

// Let's register an example store where the resolver always throws an error:
const temperatureStore = wp.data.createReduxStore( 'my-store', {
    selectors: {
        getTemperature: ( state ) => state.temperature
    },
    resolvers: {
        getTemperature: () => { throw new Error( 'Network error' ); }
    },
    reducer: () => ({}), // Bogus reducer for the example
} );
wp.data.registerStore( temperatureStore );

// Using that resolver has different results in different WordPress versions:

// In WordPress 5.9:
const promise = wp.data.resolveSelect( temperatureStore ).getTemperature();
// Error handling is unsupported, so this promise never gets rejected nor resolved.

// In WordPress 6.0:
const promise = wp.data.resolveSelect( temperatureStore ).getTemperature();
// Error handling is now supported, so this promise gets rejected with Error( 'Network error' )

The error details may be retrieved using the hasLastResolutionFailed, getLastResolutionFailure, and getResolutionState` meta-selectors available on every registered store:

wp.data.select( temperatureStore ).hasResolutionFailed( 'getTemperature' );
// the above returns: true

wp.data.select( temperatureStore ).getResolutionError( 'getTemperature' );
// the above returns: Error( 'Network error' )

wp.data.select( temperatureStore ).getResolutionState( 'getTemperature' );
// the above returns: { "state": "error", "error": Error( 'Network error' ) }

The state returned by getResolutionState is one of: "resolving", "finished", "error", undefined. The undefined indicates that the resolver hasn't been triggered yet.

[scruffian]

Theme Export

The "Export" feature in the Site Editor has been improved so that now you can export your whole theme, including all the edits you have made to your templates and styles. Previously the export function only gave you access to your template files. This change makes it possible to build a block theme using the site editor and easily share the zip file with anyone.

The Export process

The export process copies all files from the current theme into a zip file. Then it extracts the template changes that are stored in the database to files and adds them to the zip file. If these template have the same names as those in the theme, they will be overwritten, so that the database version take precedence. The same process happens for the theme.json file. There are three directories that are excluded from the export: .git, node_modules and vendor.

Unexpected changes

The export process may make a few unexpected changes to your templates and theme.json files.

1. The output of template files from the database will be sanitized for security reasons. You're most likely to notice this with any CSS variables in your template files: e.g. --wp--custom--spacing--outer would become \u002d\u002dwp\u002d\u002dcustom\u002d\u002dspacing\u002d\u002douter.
2. The properties in theme.json are now sorted alphabetically, so the first time you export you might notice some of the objects in your theme.json move position. This now gives us a standard order for these properties so in future it will be easy to know where everything should go.
3. The schema may be updated - the export will update your theme.json schema to match the version of WordPress you are using, so if you theme was created with an older version of WordPress, the schema will be updated to match the version you are on.

How to submit a theme

Once you have your exported theme, you may need to make several changes before you can submit it to the theme repository.

1. The screenshot will need to be updated, if you've made any visual changes to the homepage.
2. You will need to add a changelog entry to the readme.txt file.
3. You will need to update the version number of the theme in style.css.
4. If this is a new theme, based on an existing theme, you will also need to update the name.
5. If the theme doesn't have a license file already you will need to add one.
6. You will then need to rezip the theme with these changes.
7. You can now submit the new zip file to https://wordpress.org/themes/getting-started/.

We're looking forward to seeing more block theme submissions!

[glendaviesnz]

Gallery block

Ability to adjust gap between images added

In order to implement this the spacing of the Gallery images had to be changed from a right margin setting to the CSS gap property. Themes or plugins that use a right margin setting to manually adjust the Gallery image spacing may need to be updated to instead override the gap setting.

Default gap changed

The new block editor block gap support functionality has been used to implement this and this adds a default block gap of 0.5em so for some themes that don't explicitly set this gap the default will change from the previous 16px to 0.5em. If plugin or theme developers want to ensure that the 16px gap remains the following CSS can be added to the theme, or site custom CSS:

.wp-block-gallery {
	--wp--style--gallery-gap-default: 16px;
}

Gallery Image bottom margins removed

Some themes may have depended on the bottom margin set on the gallery images to provide a gap between two galleries. Because the gallery now uses the flex gap for spacing this bottom margin is no longer set. Themes that were relying on this unintended side effect of the image margins will need to add the following CSS in order to maintain a gap between galleries:

.wp-block-gallery {
	margin-top: 16px;
}

Gallery gutter CSS var deprecated

To keep the naming of the gap setting consistent the --gallery-block--gutter-size CSS var has been deprecated and replaced with --wp--style--gallery-gap-default. --gallery-block--gutter-size will continue to work in release 6.0 and will be removed in 6.1.

Theme authors should be able to provide compatibility for WP 5.9 and 6.0+ with the following:

.wp-block-gallery {
        --gallery-block--gutter-size: var( --wp--custom--spacing--4 );
	--wp--style--gallery-gap-default: var( --wp--custom--spacing--4 );
}

[glendaviesnz]

Separator block

Updated to use block supports color settings

In order to allow the setting of a custom opacity for each block the Separator block has been updated to use the block supports color settings. The custom opacity can then be set using the alpha channel setting of the selected color.

separator-opacity.mp4

The HMTL structure of the block is unchanged, and all of the existing classes are still in place, but two additional classes have been added - .has-alpha-channel-opacity and .has-css-opacity. These new classes have been added in order to maintain the default 0.4 opacity for all existing blocks in both the editor and the frontend. The opacity for existing blocks will only change if the block itself has its color setting changed.

If theme authors have opted in to block styles with add_theme_support( 'wp-block-styles' ); and wish to maintain the default 0.4 opacity setting for both new and old blocks the following CSS can be added:

hr.wp-block-separator.has-alpha-channel-opacity {
	opacity: 0.4;
}

[dmsnell]

Unrecognized block preservation

#38794, #38923, #39523

We've started making strides in preserving unrecognized content in the editor, also called (sometimes incorrectly) "invalid" or "missing." In situations where the editor is unable to validate a loaded block against its implementation we run into a number of cases where content has previously been lost or corrupted, notably when inner blocks are involved.

Right now we're on the journey to preserving that original unrecognized content but have a lot of corners in the project to update before it's finished. Notably when loading posts in the editor or in the code view that content will be preserved as it was loaded. Surprisingly this lets us do something we've never been able to do before: intentionally create certain kinds of broken blocks within the code editor, or modify and fix blocks in the code editor whose block implementation is missing.

Still on the list to update are smaller parts of the flow such as the array of confusing block resolution dialogs and operations as well as certain validation steps that currently fail but shouldn't.

In short, if you've been frustrated by the editor breaking your posts as soon as you hit "save" then good news is coming in 6.0.

[mcsf]

A new /patterns directory for themes

WordPress 6.0 makes it easier for themes to define their own block patterns. Themes can now define block patterns as files in the /patterns directory:

Each pattern file consists of a set of plugin-style headers followed by the pattern's actual source:

<?php
 /**
  * Title: Hello
  * Slug: my-theme/hello
  * Categories: featured, text
  */
<main><p>Hello, world!</p></main>

Motivation

While all themes benefit from this API, it is especially convenient for block themes, where conventional folders like templates, template-parts and now patterns reduce the role of functions.php as a control structure. This API also paves the way for any future theme-editing tools that integrate with the block editor.

Note that this is not a breaking change. Much like plugins, themes have been able to register block patterns since the introduction of register_block_pattern() in WordPress 5.5, and that interface is not expected to change.

Observations

• For now, the only format supported for these files is PHP. While a simpler HTML format has been considered, PHP offers theme developers an escape hatch, should the pattern have any special content that dynamic blocks haven't yet absorbed. For instance:

<img src="<?php echo esc_url( get_template_directory_uri() ); ?>/assets/hello.png">

• As a general reminder, these PHP blocks are only run upon loading the block editor in order to compute the patterns. Once inserted into a post, patterns are static.

Supported fields

• Title (required) (implicitly translatable)
• Slug (required)
• Description (implicitly translatable)
• Viewport Width
• Categories (comma-separated values)
• Keywords (comma-separated values)
• Block Types (comma-separated values)
• Inserter (yes/no)

[gziolo]

#36176 won't be included in the WP 6.0 release.

[ntsekouras]

Dev note for Allow pattern registration from directory with theme.json #38323

Pattern registration from Pattern Directory for themes

With WordPress 6.0 themes can easily register patterns from Pattern Directory through theme.json. In order to do that, themes should use the new patterns top level key in theme.json.

Within this field, themes can list patterns to register from Pattern Directory. The patterns field is an array of pattern slugs from the Pattern Directory. Pattern slugs can be extracted by the url in single pattern view at the Pattern Directory. For example in this url https://wordpress.org/patterns/pattern/partner-logos the slug is partner-logos.

{
    "version": 2,
    "patterns": [ "short-text-surrounded-by-round-images", "partner-logos" ]
}

Noting that this field requires using the version 2 of theme.json.

[mirka]

Dev note for #37160

I'm not sure if this warrants a Dev Note, so please feel free to cut it entirely if it doesn't meet the noteworthiness threshold!

---

Removed bottom margin on LineHeightControl component

A number of UI components currently ship with styles that give them bottom margins. This can make it hard to use them in arbitrary layouts, where you want different amounts of gap or margin between components.

To better suit modern layout needs, we will gradually deprecate these bottom margins. A deprecation will begin with an opt-in period where you can choose to apply the new margin-free styles on a given component instance. Eventually in a future version, the margins will be completely removed.

In WordPress 6.0, the bottom margin on the LineHeightControl component has been deprecated. To start opting into the new margin-free styles, set the __nextHasNoMarginBottom prop to true:

<LineHeightControl
  value={ lineHeight }
  onChange={ onChange }
  __nextHasNoMarginBottom={ true }
/>

[oandregal]

#36811 @oandregal

This PR has been part of 5.9, and the corresponding devnote has been published at https://make.wordpress.org/core/2022/01/08/updates-for-settings-styles-and-theme-json/ Does that devnote need any further clarification, perhaps?

[oandregal]

#38663 @oandregal

This is just a bugfix/code quality thing that doesn't introduce or modify any behavior. I've just marked it as done.

[youknowriad]

Block markup updates

Image block alignments

Historically, the image block with left, right or center alignments used to have an extra div wrapper around the figure tag to help with alignment styling.

<div class="wp-block-image alignleft"><figure><img src="someimage.jpg" alt="" width="100" height="100"/></figure></div>

In WordPress 6.0, for themes that support the layout feature, this wrapper has been removed. The markup becomes:

<figure class="wp-block-image alignleft"><img src="someimage.jpg" alt="" width="100" height="100"/></figure>

The new markup/behavior for alignment classes is consistent regardless of the block and regardless of the chosen alignment.

To minimize the impact of this change on the websites, this change is only effective for themes with a theme.json file. These themes do support the "layout" feature which automatically provides the right styles for this new markup.

Quotes and lists

The blockquote, ul and ol tag names all now come with a default value for `box-sizing` equal to `border-box`. This change has been made as a bug fix for quote and list blocks using background colors or padding.

Group block stack variation

The new Stack block is a variation of the Group block, and can be thought of as a vertical variant of the Row block. It's a flex container, meaning it has access to content justifications and block spacing. If combined with the Row block and its ability to optionally wrap onto new lines, it can enable basic responsive behaviors, such as two columns that stack to a single column on smaller displays.

Removal of data-align div wrappers

In the editor and in order to support/style block alignments, the editor used to add wrapper divs to any block that had an alignment applied to it. For themes that support the layout feature (with theme.json file), the div wrapper with the `data-align` attribute has been removed. The markup now matches exactly the frontend output.

--

This dev note can probably be merged with some of @glendaviesnz's notes above related to block markup.

[ntsekouras]

Global Styles variations

Theme authors can now create multiple theme.json variations and place them into their theme’s /styles folder. From there, users can switch between the various presets to something that suits them best.

Custom JSON files should follow the standard theme.json schema and their filename is going to be used as the variation's label in the UI(example blue.json).

Webfonts handler

A webfonts handler has been included in this release, allowing theme authors to include multiple font options within a single theme.json file or to offer vastly different styles by utilizing different font options in their multiple theme.json variations.

{
  "settings": {
      "typography": {
          "fontFamilies": []
      }
  }
}

Here's a more robust example of how to implement this new option:

{
  "settings": {
      "typography": {
	  "fontFamilies": [
				{
					"fontFamily": "-apple-system,BlinkMacSystemFont,\"Segoe UI\",Roboto,Oxygen-Sans,Ubuntu,Cantarell,\"Helvetica Neue\",sans-serif",
					"name": "System Font",
					"slug": "system-font"
				},
				{
					"fontFamily": "\"Source Serif Pero\", serif",
					"name": "Source Serif Pero",
					"slug": "source-serif-pero",
					"fontFace": [
						{
							"fontFamily": "Source Serif Pero",
							"fontWeight": "200 900",
							"fontStyle": "normal",
							"fontStretch": "normal",
							"src": [ "file:./assets/fonts/SourceSerif4Variable-Roman.ttf.woff2" ]
						},
						{
							"fontFamily": "Source Serif Pero",
							"fontWeight": "200 900",
							"fontStyle": "italic",
							"fontStretch": "normal",
							"src": [ "file:./assets/fonts/SourceSerif4Variable-Italic.ttf.woff2" ]
						}
					]
				}
			],
                    }
              }
}

Right now, there is only support for top level settings and the more granular option of defining fonts per block is not currently available. For further inspiration, theme authors can review the approach the default Twenty Twenty-Two theme has taken since it will ship with three style variations with different fonts for WordPress 6.0.

Notes

1. The variations require using the version 2 of theme.json.
2. Right now when a variation is applied its contents are still merged with the theme and core theme.json, but it's not possible to override everything. In addition you cannot overwrite a single value in an array of items.

global.styles.variations.mov

[getdave]

Wrap title of block in in a span

This is a super minor change so it might not even be worth including IMHO. If you want to however, here's a quick explaination.

The List View shows a list of each block in the editor canvas by name. It's now easier to target the block's name via CSS thanks to the addition of a wrapping element.

[SantosGuillamot]

Comments blocks

Enable legacy Post Comments block

With WordPress 6.0, there is a new set of blocks to show the Comments of a post:

• Comments Query Loop: An advanced block that displays post comments and allows for various layouts and configurations.
  • Comment Template: Contains the block elements used to display a comment, such as the title, date, author, avatar and more.
    • Avatar: Adds a user’s avatar.
    • Comment Author Name: Displays the name of the author of the comment.
    • Comment Date: Displays the date on which the comment was posted.
    • Comment Content: Displays the contents of a comment.
    • Comment Reply Link: Displays a link to reply to a comment.
    • Comment Edit Link: Displays a link to edit the comment in the WordPress Dashboard. This link is only visible to users with the edit comment capability.
  • Comments Pagination: Displays next/previous links to paginated comments where this has been enabled in the comment settings in the WordPress admin
    • Previous Page: Displays the link to the previous page of comments.
    • Page Numbers: Displays a list of page numbers for comments pagination.
    • Next Page: Displays the link to the next page of comments.

The legacy Post Comments block, which directly renders the comments.php file, has been deprecated and hidden. It will still work for themes currently using it, but it won’t appear in the inserter.

The new set of blocks provides almost the same functionalities with the benefit that the layout and styles can be customized from the Editor. However, if any user wants to re-enable the Post Comments legacy block, they can use the block registration filters and adapt it to their needs. For example, this piece of code shows the legacy block in the inserter again and removes the “deprecated” from the title:

function enable_post_comments_legacy_block( $metadata ) {
    if ( 'core/post-comments' === $metadata['name'] ) {
        $metadata['title'] = 'Post Comments';
	$metadata['supports']['inserter'] = true;
    }
    return $metadata;
}
add_filter( 'block_type_metadata', 'enable_post_comments_legacy_block' );

[DAreRodz]

New ancestor property in block.json

Block developers sometimes need to restrict where users can place their blocks. For that, developers already count on APIs like block.json's parent property or the allowedBlocks option of the useInnerBlocksProps hook that allowed developers to express some basic, direct parent-children relations between blocks.

Since WordPress 6.0, the ancestor property makes a block available inside the specified block types at any position of the ancestor block subtree. That allows, for example, to place a ‘Comment Content’ block inside a ‘Column’ block, as long as ‘Column’ is somewhere within a ‘Comment Template’ block. In comparison to the parent property, blocks that specify their ancestor can be placed anywhere in the subtree, while blocks with a specified parent need to be direct children.

This property admits an array of block types in string format, making the block require at least one of the types to be present as an ancestor.

{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 2,
    "name": "core/comment-content",
    "ancestor": [ "core/comment-template" ],
    ...
}

Block developers can also combine parent with ancestor inside block.json and use them together to express more complex relations if needed. For example:

• Parent [ 'A' ] and ancestor [ 'C' ] would work as ”parent A and ancestor C”.
• Parent [ 'A', 'B' ] and ancestor [ 'C', 'D' ] would work as ”parent (A or B) and ancestor (C or D)”.

Note that there are some edge cases uncovered by this API, like blocks that would require two or more different ancestor types simultaneously.

[fabiankaegy]

Allowing the registration of Blocks from within Themes

Up until WordPress 6.0 building blocks inside plugins was the only way possible if you wanted to use block.json. And it remains to be the recommended way to do things going forward. Blocks add functionality and therefore should be built-in plugins that stay active even when the theme gets changed.

Even with that best practice in place, there are however instances where the styling of a block is so tightly coupled with a theme that it doesn't make sense to have a block active without a given theme. This comes especially true when building very purpose build custom solutions. In these cases, you had to resort to hacky approaches to get the registration of blocks within themes to work.

This is now no longer necessary. With 6.0 the registration of blocks using block.json from within a theme technically is supported. You can use the same register_block_type function as you would inside a plugin and all the assets that you may register in the block.json file like the editorScript, style, etc. get enqueued correctly.

[zzap]

Adding 🎉 to published ones

[jorgefilipecosta]

Adding the dev note for page creation patterns #40034.

Page creation patterns

When a user creates a page, the editor starts with an empty canvas. However, that experience may not be ideal, especially since there are often possible patterns the user can use when creating a page, e.g., an about page, a contact page, a team page, etc.

Starting with WordPress 6.0, offering a set of patterns that users can choose from to create their pages is possible.
We added a modal that shows possible patterns that can be used on page creation:

The modal appears each time the user creates a new page when there are patterns on their website that declare support for the core/post-content block types. By default, WordPress 6.0 Core does not include any of these patterns, so the modal will not appear without some of these post content patterns being added.

Any theme or plugin can register a pattern with core/post-content block support and make the modal with the patterns appear. Here we provide a sample pattern that appears in this model.

	register_block_pattern(
		'my-plugin/about-page',
		array(
			'title'      => __( 'About page', 'my-plugin' ),
			'blockTypes' => array( 'core/post-content' ),
			'content'    => '<!-- wp:paragraph {"backgroundColor":"black","textColor":"white"} -->
			<p class="has-white-color has-black-background-color has-text-color has-background">Write you about page here, feel free to use any block</p>
			<!-- /wp:paragraph -->',
		)
	);

Completely disabling this functionality

By default, no modal appears because there are no post-content patterns unless a theme or plugin registers one.
If one wants to disable the modal even if there are plugins registering post-content patterns, it is possible to do so by removing the post-content block type from all patterns, as the following code sample does:

	$patterns = WP_Block_Patterns_Registry::get_instance()->get_all_registered();
	foreach ( $patterns as $pattern ) {
		if (
			! empty($pattern['blockTypes'] ) &&
			in_array('core/post-content', $pattern['blockTypes'] )
		) {
			unregister_block_pattern( $pattern['name'] );
			$pattern['blockTypes'] = array_diff( $pattern['blockTypes'], array( 'core/post-content') );
			register_block_pattern( $pattern['name'], $pattern );
		}
	}

[annezazu]

For transparency, noting that I directly edited two dev notes above:

• The style variations note to include the webfonts handler information and some examples. It would be ideal to get more eyes on this.
• The Page creation patterns note to clean up some of the language, add a screenshot, etc.

For the comments block note @SantosGuillamot , I'd highly recommend listing out all of the blocks going into the release rather than linking off to a GitHub issue. Might be easiest to just pull from this call for testing: https://make.wordpress.org/test/2022/04/08/help-test-the-comments-blocks-for-wordpress-6-0/

[SantosGuillamot]

For the comments block note @SantosGuillamot , I'd highly recommend listing out all of the blocks going into the release rather than linking off to a GitHub issue.

Thanks for the feedback, it totally makes sense 🙂 I have just updated the comment. Moreover, if I am not mistaken, the new Comments should be explained later in detail in a user-facing release note (not a dev note).

[zzap]

All dev notes from here are published or will be soon. Thank you to everyone who participated in making them, you are heros ❤️

[bph]

Thank you so much for shouldering the crunch time effort getting everything together! You are my hero @zzap 👏🎉🦸‍♀️

[ryanwelcher]

Sorry for the delay on this @bph @zzap - this covers #38535, #39723, and #38530

Updates to the @wordpress/create-block templating system

A powerful feature of the @wordpress/create-block package is the ability to create templates to allow customization of how a block is structured.

WordPress 6.0 introduces some new template variables to allow even more customization. Templates can now use the customScripts variable to create new entries in the scripts property of the package.json file and while it was already possible to defined dependences, it is now also possible to defined a list of development dependencies using the npmDevDependencies variable. In addition to these new template variables, the @wordpres/env/ package will automatically be added to the list of devDependences when the template uses the wpEnv template variable or if the —wp-env flag is passed as a command line argument.

[Mamaduka]

This general dev note for Block Locking. The other items in Lock Settings list don't need a dev note.

Block Locking Settings

WordPress 6.0 makes it easier to lock blocks using the new controls modal. The release also includes two new settings to choose who can access this option and when.

Block Editor

The new canLockBlocks setting can disable the feature globally or conditionally. Example:

add_filter(
	'block_editor_settings_all',
	function( $settings, $context ) {
		// Allow for the Editor role and above - https://wordpress.org/support/article/roles-and-capabilities/.
		$settings['canLockBlocks'] = current_user_can( 'delete_others_posts' );

		// Only enable for specific user(s).
		$user = wp_get_current_user();
		if ( in_array( $user->user_email, [ 'user@example.com' ], true ) ) {
			$settings['canLockBlocks'] = false;
		}

		// Disable for posts/pages.
		if ( $context->post && $context->post->post_type === 'page' ) {
			$settings['canLockBlocks'] = false;
		}

		return $settings;
	},
	10,
	2
);

Blocks

The lock property allows hide controls on a block type level. Example:

{
	"apiVersion": 2,
	"supports": {
		"lock": false
	}
}

[zzap]

Thank you @ryanwelcher and @Mamaduka , dev notes are published and Field guide updated.

• https://make.wordpress.org/core/2022/05/05/block-locking-settings-in-wordpress-6-0/
• https://make.wordpress.org/core/2022/05/05/updates-to-the-wordpress-create-block-templating-system/
• https://make.wordpress.org/core/2022/05/03/wordpress-6-0-field-guide/

[bph]

There is only on open item in this tracking issue:

• Add the WP version in which some JS APIs will be removed #37854

It's not necessarily a Devnote for 6.0 but while we have the attention of plugin authors, it might be good to add a note to the Misc Dev Notes section about depricated APIs for this PR as well. #37854 - See my comment

[bph]

All published.