In this dev notedev 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., you will find a collection of smaller changes to existing features and deprecated APIs and components.

Table of Contents

Fluid typography minimum font size

Following on from the fluid typography settings that were introduced in WordPress 6.1, WordPress 6.1.1 introduced a hard-coded minimum for the fluid typography rules of 14px, to ensure that the generated typography rules would not result in font sizes that were too smaller for readability in narrower viewports.

In WordPress 6.2, themes can define their own minimum font size for fluid typography rules. Depending on the theme’s requirements, sometimes the desired minimum font size value might be greater or less than the provided default of 14px. When used, the minimum font size will result in any font-sizes used that are equal to or less than the minimum being output directly as that font size. For font sizes larger than the minimum font size, the minimum font size will be used as the floor of the fluid typography calculated rule.

How to use the minimum font size in your theme

Within 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., the property settings.typography.fluid now accepts an object in addition to the existing boolean value. Setting fluid to true will use the default minimum font size of 14px; however, themes can now provide an object with a minFontSize property instead:

{
  "settings": {
    "typography": {
      "fluid": {
        "minFontSize": "15px"
      }
    }
  }
}

With the minFontSize property set to 15px in the above example, the output of a paragraph 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. set to 15px font size will be as follows with no fluid rules applied:

<p style="font-size:15px">A paragraph at 15px</p>

The output for a paragraph block set to 16px will result in the fluid rules being applied, but with 15px as the minimum font-size:

<p style="font-size:clamp(15px, 0.938rem + ((1vw - 7.68px) * 0.12), 16px);">A paragraph at 16px</p>

• Fluid font size feature introduced in 6.1: 
• Fluid typography feature tracking issue: Tracking: fluid typography  #44888
• Fluid typography PR introducing configurable minimum font size in theme.json: Fluid typography: add configurable settings for minimum font size to theme.json #42489

Props to @andrewserong for dev note (top)

Sizing controls for flex layout children

A new Layout feature was added that allows the children of container blocks with Flex type layout to provide controls to change their relative size within their parent block. This feature can be added to the container block in its __experimentalLayout settings in block.json, like so:

"__experimentalLayout": {
             "allowSizingOnChildren": true,
             "default": {
               "type": "flex"
            }
}

The controls for the child blocks will then be displayed under the “Dimensions” panel in the block sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.. If the parent’s orientation is horizontal the control will appear as “Width”, and if it’s vertical it will be “Height”.

Three options are available in this control:

• “Fit” is the default, and means the block will take up only as much space as its intrinsic dimensions;
• “Fill” makes the block stretch to take up all remaining available space within its parent;
• “Fixed” allows for setting a fixed width or height (depending on the parent’s orientation) in px, %, em, rem, vw or vh units.

(#45364)

Props to @isabel_brison for the dev note (top)

wp-block-heading CSSCSS Cascading Style Sheets. class added to every Heading block

In WordPress 6.2, the h1-h6 elements added via the heading block have a brand new wp-block-heading CSS class.

This change enables styling the heading block differently from the regular h1-h6 elements. For example, the following theme.json would add a blue background to all h1 elements and a pink background to only the h1 elements added via the cover block:

{
	"styles": {
		"elements": {
			"h1": {
				"color": {
					"background": "blue"
				}
			}
	        },
		"blocks": {
			"core/cover": {
				"elements": {
					"h1": {
						"color": {
							"background": "pink"
						}
					}
				}
			}
		}
	}
}

Work is underway to add a CSS class to every block in future WordPress releases. ( #42122)

Props to @zieladam for the Dev Note to @ajlende and @scruffian for review (top)

wp_theme_has_theme_json()

WordPress 6.2 introduces a new method called wp_theme_has_theme_json() that returns whether the active theme or its parent has a theme.json file. The goal is to provide 3rd parties with a public 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. they can use to query the active theme for this information. It deprecates the private API  WP_Theme_JSON_Resolver:theme_has_support(). Details are available in the PR #45168

Edit block style variations from theme.json

This new theme.json API allows existing coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. block style variations to be styled directly from the theme.json file. It does not currently allow adding new variations. Styles should be added as follows:

Each variation should be targeted by its name, which can be found in the block’s block.json file, under “styles”.

	"styles": {
		"blocks": {
			"core/image": {
				"variations": {
					"rounded": {
						"border": {
							"width": "10px",
							"color": "#cc3ee6"
						}	
					}
				}
			}
                }
       }

There is also a corresponding UIUI User interface in the block section of global styles, as you can see in the screenshot. (#46343)

Props to @isabel_brison for the dev note (top)

Updated caching behavior for APIs to access global styles and settings.

WordPress 5.9 added New API to access global settings & styles. In 6.2 they received updates to their caching behavior:

• wp_get_global_settings => the result is now cached per request (also known as non-persistent cache), so it’s faster.
• wp_get_global_stylesheet => the result is now cache per request (aka non-persistent) while it was cached using 1-minute transient. This caused bugs (the changes in the site editor were not reflected in the front until 1 minute later) that are fixed now.
• wp_get_global_styles_svg_filters => the result is now cached per request (aka non-persistent cache) while it was cached using 1-minute transient. While this did not cause any known bugs, it was updated for due diligence.

More details are available in this tracking issue #45171

Props to @oandregal for dev note (top)

Retaining navigation when switching themes

When users switch themes, the navigation on their site should stay the same, regardless of whether it is a block theme or a classic theme. To enable users to switch from classic themes to block themes, we have made some further refinements to the way that the navigation block imports menus from classic themes.

If a site has a classic menu, and has not yet created a navigation using the navigation block, then the navigation block will automatically import a classic menu to use. Many classic themes (for example TT1) use the primary name and slug as a convention for its main menu location. If a site has a classic menu defined at this location, then the navigation block will import this one. If not, then it will use the most recently created classic menu.

The conditions for deciding which classic menu to import are:

1. If no wp_navigation menus exist
2. If the theme has a menu defined at location called primary, use that otherwise
3. Use the most recently created classic menu

If these conditions are met, the navigation block will display the classic menu, automatically converting it to navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site.. More details via the PR (#45976)

Props to @scruffian and @jffng for content (top)

Disable Openverse categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. in new Media tab

In addition to Blocks and Patterns, with WordPress 6.2 the Inserter shows a new Media tab, giving the user fast access to the images, videos, and audio files in the Media library. It enables users to browse and search the Openverse catalog for Creative Commons licensed images. The Openverse media category can be controlled with a new public block editor setting(enableOpenverseMediaCategory). The default is to show this category, but it can be turned off by updating this setting’s value. (#47404)

settings = wp.data.select('core/block-editor').getSettings();
wp.data.dispatch('core/block-editor').updateSettings({
	...settings,
	enableOpenverseMediaCategory: false
});

add_filter(
	'block_editor_settings_all',
	function( $settings ) {
		$settings['enableOpenverseMediaCategory'] = false;

		return $settings;
	},
	10
);

Other block editor settings are listed in the handbook.

Props to @ntsekouras for the dev note (top)

Fixed focus issue after block removal.

In WordPress 6.2 the behavior of removeBlock() changed. Until then, when a block was removed, the previous block was selected and gained focus in the user interface. Occasionally, if there wasn’t any previous block available, it resulted in focus loss, which is a particularly difficult experience when using a screen reader.

With this update, the behavior of the removeBlock() action was changed to select the first parent instead. For a developer writing Custom Blocks or otherwise depending on the result of the removeBlock action, this might require an update to their code, to account for the possibility that sometimes the parent is selected on block removal. There is a way to opt-out of this behavior by passing false as the second argument to removeBlock() function.

Example code from the core/list block.

const shouldSelectParent = false;
removeBlock( parentListId, shouldSelectParent );

Details in #48204
Documentation removeBlock()

Props to @andraganescu for first draft, and to @webcommsat for review (top)

Bug fix: Global Styles for adminadmin (and super admin) users on multi-site

In WordPress 6.1 the layout block support was refactored to output CSS values for block spacing, with additional layout controls within global styles being made available. This resulted in a 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. for admin users without the unfiltered_html capability (e.g. admin users within a multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site instance) where block spacing or layout content sizes were not saved when updated within the global styles interface. (#45520) The cause was that within the Theme JSON class, theme.json values are filtered for users without the unfiltered_html capability based on a lookup to a direct CSS property, e.g. margin or padding. For layout features, the styling rules are stored in indirect properties that don’t directly map to a real CSS property, e.g. blockGap and contentSize.

For WordPress 6.2 (and backported to WordPress 6.1.2) this issue is resolved by the Theme JSON class storing a list of indirect properties (INDIRECT_PROPERTIES_METADATA), with a mapping between a CSS property to use for validation, and the path to the indirect property as stored in theme.json. In this way, blockGap will be validated against the CSS gap property, and contentSize against the CSS max-width property, etc.

For themes using layout features, no changes are required, as the bug fix is an internal implementation detail of how Theme JSON styles are validated and output.

See #46388, #46712

Props to @andrewserong for the dev note (top)

Removal of deprecated APIs and Components

formatting prop in RichText component

The formatting prop have been deprecated in WordPress 5.4 release and is not available anymore starting from WordPress 6.2. If you want to define the available formats when using the RichText component, use the allowedFormats prop instead. (#46106)

Props to @youknowriad for dev note (top)

useAnchorRef hook not deleted in 6.3

The deprecated useAnchorRef hook from the @wordpress/rich-text package will not be deleted in WordPress 6.3, as initially planned. (#45302)

DateTimePicker deprecated prop removal postponed to 6.3

The removal of the __nextRemoveHelpButton and __nextRemoveResetButton props on the DateTimePicker component in @wordpress/components, initially scheduled for 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/ 14.6, has been postponed to the Gutenberg 15.8 release. (#46006)

Props to @mciampini for above dev note (top)

Deprecate non-string descriptions

In WordPress 6.2, non-strings as block descriptions have been deprecated.

Previously, we could register a block with a non-string description (like a ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. Node or any other 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/. object for example). Another way to achieve that was to use the blocks.registerBlockType 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. and change the description with a non-string there.

While there could be niche edge cases that found non-string descriptions useful, contributors discovered that this could cause unexpected bugs and thus have decided to deprecate it. This makes it clearer that the recommended type for block descriptions should be of type string only.

For context and more information, see #44455 and #44233. (top)

Removal of the Navigation Editor screen and associated package

The Navigation Editor screen was an experimental feature of the Gutenberg 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 that contributors worked on as a potential replacement for the classic Menus screen using a block-based paradigm. The code for this feature existed within a dedicated @wordpress/edit-navigation package.

As the Navigation project has evolved, however, the requirement for a dedicated screen has become less pronounced, with features originally proposed for/included within the screen being incorporated into the Navigation block itself.

During the 6.1 cycle, due to lack of contributions, the experiment was informally deprecated in the Plugin by being removed from the Experiments screen in the Gutenberg Plugin settings page.

With the arrival of list view editing for the Navigation block in WordPress 6.2, menus can now be edited away from the editor canvas, and therefore it is finally time to formally remove the experiment from the codebase.

The @wordpress/edit-navigation package has now been removed from the Gutenberg repository and then associated package unpublished from npm. (#47055)

Props to @get_dave for content, @andraganescu and @talldanwp for review (top)

Props for review of the full post to @mciampini and @webcommsat

#6-2, #dev-notes, #dev-notes-6-2