Add new prop to ServerSideRender component

WordPress 6.2 introduces a new skipBlockSupportAttributes prop to exclude attributes and styles related to 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. supports in the ServerSideRender component. This makes it easier to properly add support to blocks with the ServerSideRender components.

ServerSideRender is a component used for server-side rendering a preview of dynamic blocks to display in the editor. By passing the attributes prop to this component, it is processed on the server side and the block receives the rendered result.

ServerSideRender component should be regarded as a fallback or legacy mechanism, it is not appropriate for developing new features against. New blocks should be built in conjunction with any necessary REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. endpoints, so that 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/. can be used for rendering client-side in the edit function. This gives the best user experience, instead of relying on using the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher render_callback. The logic necessary for rendering should be included in the endpoint, so that both the client-side JavaScript and server-side PHP logic should require a minimal amount of differences.

import ServerSideRender from '@wordpress/server-side-render';
const MyServerSideRender = () => (
	<ServerSideRender
		block="core/archives"
		attributes={ attributes }
	/>
);

If you add block supports to the block that contains this component, the problem is that the styles from the block support will be applied to both the block wrapper element and the rendered HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. by ServerSideRender component. For example, if you opt for padding and margin as block support, and those styles are applied to the block, you will have double spaces.

<div
	...
	class="block-editor-block-list__block wp-block wp-block-archives"
	style="padding: 10px; margin: 10px;"
>
	<div inert="true" class="components-disabled">
  		<div>
  			<ul
				style="padding-top:10px;padding-right:10px;padding-bottom:10px;padding-left:10px;margin-top:10px;margin-right:10px;margin-bottom:10px;margin-left:10px;"
				class="wp-block-archives-list wp-block-archives"
			>
				<li><a href="http://example.com">Hello World</a></li>
			</ul>
		</div>
	</div>
</div>

By opting in to the new skipBlockSupportAttributes prop introduced in WordPress 6.2, all attributes related to block support will be removed before rendering on the server side, and you will be able to get proper rendering results.

import ServerSideRender from '@wordpress/server-side-render';
const MyServerSideRender = () => (
	<ServerSideRender
 		skipBlockSupportAttributes
		block="core/archives"
		attributes={ attributes }
	/>
);

However, if block styles are already defined in the global style or in theme.json, those styles will take precedence and individual block’s overrides may not be applied. In such cases, explicitly handling the block support to be passed to the ServerSideRender component will produce the intended result.

import ServerSideRender from '@wordpress/server-side-render';

const serverSideAttributes = {
	...attributes,
	style: {
		...attributes?.style,
		// Ignore styles related to margin and padding.
		spacing: undefined,
	},
};

const MyServerSideRender = () => (
	<ServerSideRender
		// All block support attributes except margins and padding are passed.
 		attributes={ serverSideAttributes }
		block="core/archives"
		attributes={ attributes }
	/>
);

wp.components.ServerSideRender

The ServerSideRender component has moved to its own package/script in WordPress 5.3 and accessing it using wp.components.ServerSideRender has been deprecated since. Starting WordPress 6.2, you should be able to access it directly using wp.serverSideRender. (#46106)

Props to @andrewserong, @bph, @aaronrobertshaw @youknowriad for reviewing.

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

Minimum height dimensions block support

In WordPress 6.2, a new minimum height 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. support feature has been added, with the Group and Post Content blocks opted-in by default. For themes using the appearanceTools feature in theme.json, the control will be available in the inspector controls, under Dimensions. It is not exposed by default, and users can access the control via the Dimensions panel’s menu. (#45300)

The feature allows users to set a Group or Post Content block to have a minimum height, similar to the control that exists for the Cover block. An example use case is to ensure that a post content area has a minimum height, forcing a footer area to render lower on the page, even if a page has little content. For this reason, it can be quite useful to use viewport relative units when setting minimum height, e.g. 100vh for a block that takes up the entire height of the viewport.

Setting the minimum height for the Stack variation of the Group block is also useful when combined with the new vertical alignment tools added in 6.2 introduced in this Gutenberg PR, as it allows users to align the blocks within the minimum height of the Stack to be at the topcenterbottom positions within the block, or for the blocks to be aligned via space-between.

How to add minHeight support to a theme

There are two ways to add support for the minHeight setting to a block theme. The simplest is to opt in to the appearanceTools setting, which automatically enables several design tools (read more in the Developer Handbook).

For themes that wish to have more granular control over which UIUI User interface tools are enabled, the minHeight dimensions support can be opted into by setting settings.dimensions.minHeight to true in theme.json. For example:

{
	"settings": {
		"dimensions": {
			"minHeight": true

For styling blocks globally, minHeight can also be set either within the global styles interface, or within theme.json. For example, the Post Content block can be set to have a minimum height of 70vh by setting styles.blocks.core/post-content.dimensions.minHeight to 70vh in theme.json:

{
	"styles": {
		"blocks": {
			"core/post-content": {
				"dimensions": {
					"minHeight": "70vh"
				}

How to add minHeight support to a custom block

In the block’s block.json file, add the supports.dimensions.minHeight property, and set it to true to enable the minimum height control. For static blocks, the min-height CSSCSS Cascading Style Sheets. rule will be saved as an inline style to post content. For dynamic blocks, the min-height rule will be injected into the style attribute returned as part of a call to get_block_wrapper_attributes. For more information on outputting block supports in dynamic blocks, read the entry in the Developer Handbook.

Further reading

Props to @bph and @webcommsat for review.

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

Google Fonts are included locally in bundled themes

Due to privacy concerns, the themes from Twenty Twelve to Twenty Seventeen will not fetch their fonts from Google addresses, starting with the next version.

Twenty Twelve3.9
Twenty Thirteen3.8
Twenty Fourteen3.6
Twenty Fifteen3.4
Twenty Sixteen2.9
Twenty Seventeen3.2


Each theme would serve a new stylesheet from the theme directory, under the site’s domain. With multiple fonts, Twenty Thirteen creates a reference like this:

<link rel='stylesheet' id='twentythirteen-fonts-css' href='https://example.com/wp-content/themes/twentythirteen/fonts/source-sans-pro-plus-bitter.css?ver=20230328' media='all' />

If you have edited or removed the font stylesheet in a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. or 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, please verify that your site will work properly with this change.

Language support

When a language has disabled certain custom fonts, the stylesheet should continue to respect that setting.

Google Fonts had offered all character sets, ignoring any specified in the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, so the new styles for all six themes likewise gather the font files for any character sets. Modern browsers select only the sets they need for the page.

Developers may still choose only certain character subsets, either to create a reduced stylesheet or to use in a preload resource hint. Creating an array of language codes could help, mapping them to their script families.

Fixing the editor style within a custom theme-setup function

Twenty Fourteen, Twenty Fifteen and Twenty Sixteen have allowed custom overrides to their setup functions in a child theme.

  • twentyfourteen_setup()
  • twentyfifteen_setup()
  • twentysixteen_setup()

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, the new font stylesheet URL needs to be relative in the add_editor_style() function, or else it would try fetching fonts from a nonexistent wp-admin URL. If a child theme replaces the setup function, it should remove the theme directory before including the fonts in the editor style array. Twenty Fourteen has this (arranged in fewer lines):

$font_stylesheet = str_replace(
	array(
		get_template_directory_uri() . '/',
		get_stylesheet_directory_uri() . '/'
	),
	'',
	twentyfourteen_font_url()
);
add_editor_style(
	array(
		'css/editor-style.css',
		$font_stylesheet,
		'genericons/genericons.css'
	)
);

Removing the font stylesheet

Twenty Fifteen and Twenty Sixteen have allowed replacing the font stylesheet since their debut, and the upcoming versions of the other four themes will enable the same. (Previous versions of those four would cause an error by declaring the function twice.)

To remove the font stylesheet and use system fonts, you could return an empty string in the child theme’s functions.php.

function twentyfifteen_fonts_url() {
	return '';
}

To protect against errors in older versions of Twenty Twelve, Twenty Thirteen, Twenty Fourteen or Twenty Seventeen, the child theme could establish a minimum version for the parent theme before declaring the function.

if ( version_compare( wp_get_theme( 'twentythirteen' )->get( 'Version' ), '3.8', '>=' ) ) {
	function twentythirteen_fonts_url() {
		return '';
	}
}

Including a custom set of fonts in the child theme

A child theme could include a different set of fonts and its own stylesheet. For example, a site that needs additional weights and styles for Montserrat—but does not use Twenty Sixteen’s other fonts—could have this in its functions.php:

function twentysixteen_fonts_url() {
	return get_stylesheet_directory_uri() . '/fonts/montserrat-all.css';
}

Classic Editor would require special considerations for the new URL:

  1. The above example uses '/fonts/montserrat-all.css' because Twenty Sixteen has '/fonts/montserrat.css' in its directory. If the child theme’s filename and directory match a stylesheet in the parent theme, the editor would fetch both stylesheets. Child themes that already have a font stylesheet with the same name and directory could use the mce_css 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. to remove the extra file.
  2. If the child theme font URL includes a version query string, whether hardcoding ver=1.0 or using add_query_arg(), Classic Editor would ignore the entire stylesheet. If the version is important on the front end, the function could add the parameter only when it is not an administration page.

Child themes also could build similar stylesheets to override choices in the parent font stylesheet. If you want to extend the time limit for fonts to load and replace system fonts, you could change the font-display property to swap and refer to the parent theme’s font files within your theme’s stylesheet.

/* montserrat-latin-400-normal */
@font-face {
	font-family: 'Montserrat';
	font-style: normal;
	font-display: swap;
	font-weight: 400;
	/* Go up two levels if this stylesheet is at '/fonts/montserrat-all.css' in the child theme. */
	src:
		url('../../twentysixteen/fonts/montserrat/montserrat-latin-400-normal.woff2?ver=25') format('woff2'),
		url('../../twentysixteen/fonts/montserrat/montserrat-all-400-normal.woff?ver=25') format('woff');
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

Adjusting the query string

If you amended parameters in the Google Fonts URL with add_query_arg or remove_query_arg, those adjustments would not have the desired effect anymore.

Without a child theme, the default stylesheet can be replaced within a plugin:

function wpdocs_replace_twentyseventeen_font_stylesheet( $src, $handle ) {
	if ( 'twentyseventeen-fonts' === $handle ) {
		$src = plugins_url( '/css/new-font.css', __FILE__ );
	}
	return $src;
}
add_filter( 'style_loader_src', 'wpdocs_replace_twentyseventeen_font_stylesheet', 10, 2 );

// Adjust for Classic Editor, too.
function wpdocs_replace_twentyseventeen_font_for_classic_editor( $mce_css ) {
	if ( ! empty( twentyseventeen_fonts_url() ) ) {
		$mce_css = str_replace(
			twentyseventeen_fonts_url(),
			plugins_url( '/css/new-font.css', __FILE__ ),
			$mce_css
		);
	}
	return $mce_css;
}
add_filter( 'mce_css', 'wpdocs_replace_twentyseventeen_font_for_classic_editor', 11 );

Continuing to use Google Fonts

If you created a custom Google Fonts URL and you do not need to change it to meet privacy laws, you may want to restore the preconnect resource hint filter. A PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher comment disables it, but either a child theme or a plugin can add the filter again. Each theme has its own filter callback name:

add_filter( 'wp_resource_hints', 'twentytwelve_resource_hints', 10, 2 );

For more information, please see ticketticket Created for both bug reports and feature development on the bug tracker. #55985.

Props to @audrasjb for help with the title, @milana_cap for formatting help, @bph for review.

#6-2, #bundled-theme, #core-privacy, #core-themes, #dev-notes, #dev-notes-6-2

get_page_by_title() deprecated

In WordPress 6.2, the get_page_by_title() function has been deprecated in favour of using WP_Query (#57041). Unlike the deprecated function, WP_Query can only be run after plugins and pluggable functions have loaded, on the plugins_loaded action or later.

Due to limitations with the deprecated functions database query, it could return different results depending on the database version and/or engine used. Switching to WP_Query will ensure you receive the same results regardless of the setup of your server.

To achieve an equivalent database query via WP_Query, the following arguments can be used.

$query = new WP_Query(
	array(
		'post_type'              => 'page',
		'title'                  => 'Sample Page',
		'post_status'            => 'all',
		'posts_per_page'         => 1,
		'no_found_rows'          => true,
		'ignore_sticky_posts'    => true,
		'update_post_term_cache' => false,
		'update_post_meta_cache' => false,
		'orderby'                => 'post_date ID',
		'order'                  => 'ASC',
	)
);

if ( ! empty( $query->post ) ) {
	$page_got_by_title = $query->post;
} else {
	$page_got_by_title = null;
}

The same result can also be achieved via the get_posts() wrapper for WP_Query(). In this case, you can replace the code with the following:

$posts = get_posts(
	array(
		'post_type'              => 'page',
		'title'                  => 'Sample Page',
		'post_status'            => 'all',
		'numberposts'            => 1,
		'update_post_term_cache' => false,
		'update_post_meta_cache' => false,			
		'orderby'                => 'post_date ID',
		'order'                  => 'ASC',
	)
);

if ( ! empty( $posts ) ) {
	$page_got_by_title = $posts[0];
} else {
	$page_got_by_title = null;
}

Ensuring the page is accessible

Due to the database query used by get_page_by_title(), it was possible the result returned from the database was not intended to be accessible by the user and that linking to the result would lead to a File Not Found error.

The code above reproduces this behaviour. If you wish to avoid this edge, then leave the post_status parameter out of the code above will resolve your issue.

Props to @afragen@spacedmonkey, @milana_cap, @bph@webcommsat for proofreading.

#6-2, #dev-notes

Editor Components updates in WordPress 6.2

This post lists notable changes to the @wordpress/components package for the WordPress 6.2 release:

Deprecating bottom margin on control components

Several UIUI User interface components currently ship with styles that give them top and/or bottom margins. This can make it hard to reuse 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 outer 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.

Continuing the effort started in previous releases, for the WordPress 6.2 release we focused on the BaseControl component and its consumers. While the effort is still ongoing, the outer margins on the following components have been deprecated. (Links all go to the WordPress Storyboard)

To start opting into the new margin-free styles, set the __nextHasNoMarginBottom prop to true.

<SelectControl
  options={ selectOptions }
  value={ selectValue }
  label={ __( 'Label' ) }
  onChange={ onSelectChange }
  __nextHasNoMarginBottom={ true }
/>

To better suit modern layout needs, we will gradually deprecate these outer margins. A deprecation will begin with an opt-in period where you can decide 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.2, the bottom margin on the URLInput component has been deprecated.

To start opting into the new margin-free styles, set the __nextHasNoMarginBottom prop to true:

<URLInput
     __nextHasNoMarginBottom
     className={ className }
     value={ attributes.url }
     onChange={ ( url, post ) => setAttributes( { url, text: (post &&     post.title) || 'Click here' } ) }
/>

Contributors working on the Components package are in the process of migrating all internal usages to use the new __nextHasNoMarginBottom prop. Once all usages are migrated, an official deprecation will be added to the BaseControl component.

For more information visit #38730(top)

Increased consistency when applying inline styles and class names to control components

To improve consistency across the @wordpress/components package, any inline styles passed to the InputControl component through its style prop will be applied to its outer wrapper element, instead of an inner input wrapper element.

Similarly, any class names applied to the UnitControl component through its className prop will be applied to its outer wrapper element, instead of an inner input wrapper element. As a consequence of this change, the components-unit-control-wrapper class name and the __unstableWrapperClassName prop have been removed from the UnitControl component.

These changes may affect usages of other components relying on InputControl and UnitControl, such as NumberControl, RangeControl, HeightControl, etc.

For more information visit #45340 and #45139(top)

Parent navigation support & named arguments for the Navigator component

The Navigator component from the @wordpress/components package has been enhanced with two additional features:

  • it can now match named arguments (ie. /product/:productId);
  • it now offers a way to navigate to the parent screen via the goToParent function and the NavigatorToParentButton component.

These two features assume that NavigatorScreens are assigned paths that are hierarchical and follow a URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org-like scheme, where each path segment is separated by the / character.

For more information visit #47827 and #47883(top)

Absence of inert polyfill

The Disabled component internally relies on the inert property. To manage expectations when interacting with the component in browsers where the inert attribute is not supported, the component’s docs were updated to clarify that the polyfill for the inert property needs to be added by the consumer of the @wordpress/components package.

For more information visit #45272(top)

Using the placement prop for Popover-based components

With the recent refactor of the Popover component to use the floating-ui library, the placement prop has become the recommended way to determine how the component positions with respect to its anchor. While the older position prop is still supported, we’re making changes towards removing all of its usages in 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/ repository and deprecating it.

As part of these efforts, the position prop has been marked as deprecated on the following components:

  • Dropdown from the @wordpress/components package
  • URLPopover component from the @wordpress/block-editor package

Consumers of these components should be using the new placement prop instead.

For more information visit #46865 and #44391(top)

Added default values to props on ColorPalette, BorderBox and BorderBoxControl

Many props of the ColorPaletteBorderBox and BorderBoxControl components from the @wordpress/components package have been assigned a default value to better reflects each prop’s purpose.

The Storybook pages for each component have been updated: ColorPalette, BorderControl and BorderBoxControl to reflect those changes.

For more information visit #45463(top)

__experimentalHasMultipleOrigins removed from selected components

The __experimentalHasMultipleOrigins prop has been removed from the ColorPaletteGradientPickerBorderControl and BorderBoxControl components in the @wordpress/components package.

The prop has been replaced by a check in the ColorPalette component which automatically detects whether the colors passed through the colors prop has a single or multiple color origins.

For more information visit #46315(top)

Props to @0mirka00 and @brookemk for the help in writing these 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..

Props to @bph and @webcommsat for reviewing this post.

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

I18N Improvements in 6.2

Various internationalization (i18n) improvements are in WordPress 6.2, and this developers note will focus on these.

Make it easier to switch to a user’s localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English.

A while back, WordPress 4.7 introduced user admin languages and locale switching. With every user being able to set their preferred locale, it’s crucial to use locale switching to ensure things like emails are sent in that locale. That’s why you would see a lot of code like switch_to_locale( get_user_locale( $user ) ) in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and in plugins.

Not only is this very repetitive, it also causes limitations when used in combination with things like the Preferred Languages feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., where one would like to fall back to another locale if the desired one is not available.

To improve this, WordPress 6.2 provides a new switch_to_user_locale() function that takes a user ID, grabs the user’s locale and stores the ID in the stack, so that at each moment in time you know whose locale is supposed to be used.

Together with this enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature., the WP_Locale_Switcher class has been updated to 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. both locale and determine_locale with the switched locale. This way, anyone using the determine_locale() function will get the correct locale information when switching is in effect.

Core already makes use of this new function, and plugins and themes are of course encouraged to do so as well.

See #57123 for more information.

wp_get_word_count_type()

In #56698, the locale’s word count type (i.e. whether they count words or characters), has been made part of the WP_Locale class.

Previously, to get that information, plugins and themes had to do something similar as core and use code like _x( 'words', 'Word count type. Do not translate!' ). All such translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. strings in core have already been replaced with the new wp_get_word_count_type() function (which is a wrapper around WP_Locale::get_word_count_type()). So if you have been using those translation strings in your code, you can now switch to this new function too!

Install new translations when editing your profile

Ever since the aforementioned user admin language feature was introduced, users have been able to change their preferred language in the user profile by choosing from the list of already installed languages. New languages could only be installed via the General Settings page.

Starting with WordPress 6.2, you don’t have to go to the settings page anymore if you quickly want to change your user language to a new one—if you have the necessary capabilities to install languages of course, which by default only admins have.

See #38664 for full context.

Screenshot of the profile edit screen, showing the language chooser dropdown where users can now also choose languages that have not yet been installed.
Users with the necessary capabilities can now install new languages via the profile edit screen.

Translator comments for screen reader strings

In r55276 / #29748, all translatable strings intended for screen readers have been marked as such via translator comments.

This aims to provide better context for translators and make it easier to determine that some strings contain hidden 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) text and are not displayed in the UIUI User interface.

Props @ocean90 and @webcommsat for reviewing this post.

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

Customize settings for any block in WordPress 6.2

WordPress 6.2 introduces a new client-side 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. that allows developers to modify 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. settings before the editor is rendered.

The filter is called blockEditor.useSetting.before and can be used in the 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/. code as follows:

import { addFilter } from '@wordpress/hooks';

/**
 * Restrict the spacing units that can be
 * selected in the Column block to pixels:
 */
addFilter(
	'blockEditor.useSetting.before',
	'myPlugin/useSetting.before',
	( settingValue, settingName, clientId, blockName ) => {
		if ( blockName === 'core/column' && settingName === 'spacing.units' ) {
			return [ 'px' ];
		}
		return settingValue;
	}
);

This example will restrict the available spacing units for the Column block to just pixels. A similar restriction could be applied using theme.json filters or directly in a theme’s 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. file using block-level settings.

However, the blockEditor.useSetting.before filter is unique because it also allows developers to modify settings according to the block’s location, neighboring blocks, the current user’s role, and more. The possibilities for customization are extensive.

In the following example, text color controls are disabled for the Heading block whenever the block is placed inside of a Media & Text block.

import { select } from  '@wordpress/data';
import { addFilter } from '@wordpress/hooks';

/**
 * Disable text color controls on Heading blocks
 * when placed inside of Media & Text blocks.
 */
addFilter(
	'blockEditor.useSetting.before',
	'myPlugin/useSetting.before',
	( settingValue, settingName, clientId, blockName ) => {
		if ( blockName === 'core/heading' ) {
			const { getBlockParents, getBlockName } = select( 'core/block-editor' );
			const blockParents = getBlockParents( clientId, true );
			const inMediaText = blockParents.some( ( ancestorId ) => getBlockName( ancestorId ) === 'core/media-text' );

			if ( inMediaText && settingName === 'color.text' ) {
			    return false;
			}
		}

		return settingValue;
	}
);

The addition of this filter provides developers with more control over what block settings are presented to the user, enabling them to curate the editor experience like never before.

Props to @alecgeatches, @zieladam, and @aurooba for contributing to the 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. and @bph and @webcommsat for review.

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

Style Book preview of blocks in global styles

In WordPress 6.2, a new feature has been added to the global styles interface that allows a user to preview every 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. that can be inserted into their site. The Style Book can be accessed via the eye icon in the Styles headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. within global styles. It provides an at-a-glance preview of how global styles will affect the display of any block, without the user having to insert those blocks into a template.

Following the structure of the block inserter, the Style Book will be filled in with all blocks that can be inserted by this tool and also have an “example” set. ”  example is a parmeter in the block.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. file..

The categories/tabs in the Style Book also follow the same categories used by the block inserter. For block developers that already set an example for custom blocks, no additional parameters are required for the block to be visible in the Style Book.

Within the Style Book, a user can click on a preview of a block and it will navigate them to the block-level global styles where the block’s styling can be adjusted. Overall, this makes it easier for a user to preview changes to block-level global styles, without having to insert the block within the current template.

Even if a block has no direct styling controls, it is still valuable for blocks to appear in the Style Book, so that the user can see how the overall site design and styling settings will affect every block that can be inserted. For example, site-wide background and text colors, or font family or font sizes generally affect how all blocks will be displayed.

However, there still might be cases where block developers wish to hide blocks from being inserted and therefore also hide them from the Style Book. The two ways to hide blocks from the Style Book are:

  • If the block has supports.inserter set to false within the block.json file, then the block will be hidden from both the block inserter and the Style Book.
{
	"supports": {
		"inserter": false
	}
}

  • If the block does not have an example set.

The conditions of when to show or hide blocks from the Style Book are intentionally tied to the same logic as used by the block inserter. The principle behind the Style Book is that if a user can insert or view a preview of the block, then it should also be previewed within the context of global styles.

Props to @bph, @webcommsat and @oglekler for review.

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

Update to content only editing filter namespace

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. is a follow up to a previous dev note: Content only editing and other locking updates.

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/ PR, #43037, which introduced the feature, added a 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. hook with the same namespace ('core/style/with-block-controls') as an existing filter hook that implements block support style controls.

addFilter(
	'editor.BlockEdit',
	'core/style/with-block-controls',
	withBlockControls
);

The risk of having two 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. with the same namespace is that any attempt to remove the filter will, possibly unintentionally, affect them both.

removeFilter( 'editor.BlockEdit', 'core/style/with-block-controls' );

The Block Editor documentation states the following:

One notable difference between the JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. and PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher hooks 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. is that in the JS version, addAction() and addFilter() also need to include a namespace as the second argument. Namespace uniquely identifies a callback in the form vendor/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/function.

A subsequent Gutenberg PR #46344 has renamed the filter hook namespace for the content lock filter hook to 'core/content-lock-ui/with-block-controls'. This now makes the namespace unique within the context of 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.

addFilter(
	'editor.BlockEdit',
	'core/content-lock-ui/with-block-controls',
	withBlockControls
);

No functionality has been affected. The change will ship with Gutenberg 14.8.

Props to @talldanwp for technical assistance and @milana_cap, @aaronrobertshaw and @andrewserong for reviewing.

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