The Navigation block will no longer forcefully propagate its font-size configurations down to the markup of individual child blocks (core/navigation-link, core/navigation-submenu, core/page-list, and core/home-link).

Currently, font size is propagated to every navigation item. Because relative units multiply against their parent container’s computed size, this caused extreme compounding (e.g., 1.5em → 2.25em → 3.375em), severely breaking the layout of deeply nested dropdown menus.

By removing the explicit application on child items, the Navigation block now safely relies on standard CSS Cascading Style Sheets. text inheritance. This fixes an issue where the editor canvas and the frontend displayed mismatched typography sizes when child links had their own explicit font sizes overridden by parent propagation.

As for backwards compatibility, theme developers can restore the legacy font-size propagation behavior by applying the following filter 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. in their functions.php:

/**
 * Restores font size classes on Navigation child blocks.
 * Use this if your theme targets has-{slug}-font-size on nav items directly.
 */
function restore_nav_item_font_size( $block_content, $parsed_block, $block ) {
    $context = $block->context;

    $has_named_font_size  = array_key_exists( 'fontSize', $context );
    $has_custom_font_size = isset( $context['style']['typography']['fontSize'] );

    if ( ! $has_named_font_size && ! $has_custom_font_size ) {
        return $block_content;
    }

    $target_tag = 'core/page-list' === $block->name ? 'UL' : 'LI';

    $processor = new WP_HTML_Tag_Processor( $block_content );

    if ( ! $processor->next_tag() || $target_tag !== $processor->get_tag() ) {
        return $block_content;
    }

    if ( $has_named_font_size ) {
        $processor->add_class( sprintf( 'has-%s-font-size', $context['fontSize'] ) );
    } elseif ( $has_custom_font_size ) {
        $existing_style  = $processor->get_attribute( 'style' ) ?? '';
        $font_size_style = sprintf(
            'font-size: %s;',
            wp_get_typography_font_size_value(
                array( 'size' => $context['style']['typography']['fontSize'] )
            )
        );
        $processor->set_attribute( 'style', $existing_style . $font_size_style );
    }

    return $processor->get_updated_html();
}

add_filter( 'render_block_core/navigation-link', 'restore_nav_item_font_size', 10, 3 );
add_filter( 'render_block_core/navigation-submenu', 'restore_nav_item_font_size', 10, 3 );
add_filter( 'render_block_core/home-link', 'restore_nav_item_font_size', 10, 3 );
add_filter( 'render_block_core/page-list', 'restore_nav_item_font_size', 10, 3 );

References:

• Navigation block: Stop font size setup propagation to children blocks (causes font size multiplication issue!)
• Prevent font-size propagation in Navigation items causing em compounding

It’s now possible to target a specific block variation in a block transform, via the optional variationName property:

transforms: {
	to: [
		{
			type: 'block',
			blocks: [ 'core/group' ],
			variationName: 'group-grid',
			transform: ( attributes, innerBlocks ) => {
				return createBlock(
					'core/group',
					{
						...attributes,
						layout: { type: 'grid' },
					},
					innerBlocks
				);
			},
		},
	],
}

For programmatic transforms, switchToBlockType now accepts the target variation name as an optional third argument:

switchToBlockType( blocks, 'core/group', 'group-grid' );

References:

• Add Transform from Columns -> Grid
• Try allowing transforms to a variation of another block

The @wordpress/blocks package and wp.blocks global have two functions, __experimentalCloneSanitizedBlock and __experimentalSanitizeBlockAttributes.

These functions will continue to work in WordPress 7.1, but they will now log deprecation messages to the console. The functions have been replaced with stable versions that do not have the __experimental prefix.

Developers should replace any usage of __experimentalCloneSanitizedBlock with cloneSanitizedBlock and __experimentalSanitizeBlockAttributes with sanitizeBlockAttributes.

References:

• Blocks package: Stabilize cloneSanitizedBlock and sanitizeBlockAttributes

@wordpress/blocks replaced showdown with marked for parsing pasted Markdown. The parser is internal to pasteHandler() and was never exported, so no code changes are needed.

Output should be equivalent, but edge cases now follow the CommonMark and GFM specs. Consumers calling pasteHandler() directly should re-test representative Markdown input against the blocks it produces.

References:

• Blocks: Migrate Markdown converter from showdown to marked

WordPress 7.1 introduces a disableContentOnlyForTemplateParts editor setting, letting themes and plugins restore standard block editing for Template Parts instead of the content-only editing used by default.

Set it via the block_editor_settings_all filter in PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher:

add_filter( 'block_editor_settings_all', function ( $settings ) {
	$settings['disableContentOnlyForTemplateParts'] = true;
	return $settings;
} );

Or at runtime from JavaScript 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:

wp.data.dispatch( 'core/block-editor' ).updateSettings( {
	disableContentOnlyForTemplateParts: true,
} );

When the editor is in template-locked rendering mode, content-only editing for Template Parts is always disabled regardless of this setting.

There is no impact on backward compatibility: leaving the setting unset preserves the existing default behavior.

For a session-only toggle while editing, the command palette also offers an “Enable/Disable content-only editing for patterns and template parts” command.

References:

• Block Editor: disableContentOnlyForTemplateParts cannot be overridden via PHP filter
• Block Editor: Allow overriding disableContentOnlyForTemplateParts setting

WordPress 7.1 lowers the CSS specificity of the preset utility classes (.has-*-color, -background-color, -border-color, -gradient-background, -font-size, -font-family) generated for block-level presets, so they match the specificity of top-level (root) presets.

Presets defined at the block level, that is, via theme.json settings.blocks.<block> or the wp_theme_json_data_* filters, used to prepend the block selector to the preset class, raising its specificity above top-level presets.

The block selector is now wrapped in :where(), which contributes no specificity.

Before:

.has-accent-color                { color: … !important; } /* top level:   0-1-0 */
p.has-accent-color               { color: … !important; } /* block level: 0-1-1 */
.wp-block-group.has-accent-color { color: … !important; } /* block level: 0-2-0 */

After:

:where(p).has-accent-color               { color: … !important; } /* 0-1-0 */
:where(.wp-block-group).has-accent-color { color: … !important; } /* 0-1-0 */

Scoping is unchanged. The rule still only matches the class on/within that block. Top-level presets are unchanged.

The reason for the change is that block-level presets out-ranking top-level ones was inconsistent and broke the responsive style states also landing in 7.1. Preset classes and responsive state styles both use !important, so specificity picked the winner. For example, a block-level palette colour set for Desktop overrode one set for Mobile. At equal specificity the responsive rule now wins on source order, as intended.

Affected are themes and plugins that register block-level presets and depend on their former, higher specificity. For example custom CSS written to slot between a top-level and a block-level preset. Such rules now tie block-level presets at 0-1-0.

The risk of regression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. is relatively contained because:

• presets flow through CSS variables, so only collision tie-breaks change, not rendered values.
• only !important author CSS ever competed with presets, and the drop is a single component in each case: 0-1-1 to 0-1-0 for element-based block selectors, 0-2-0 to 0-1-0 for class-based ones.
• :where() is already used throughout Gutenberg 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/ to manage specificity.
• Realistic collisions are dominated by the responsive-states bug 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. this fixes. Responsive states are new to 7.1.

References:

• 7.1 Bug when using JSON filter for text colors in Responsive style states for blocks
• Theme JSON: Level block-level preset class specificity with :where()

Several REST 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 ignore the page and per_page collection parameters and always return the entire collection. getEntityRecords() applied client-side pagination to every entity, slicing responses to the default per_page of 10 and ignoring remaining records. That was a bug.

The unintended behavior has been corrected: slicing now only happens for entities that declare supportsPagination: true, and everything else returns the full collection.

The common per_page: -1 workaround is no longer necessary, though passing it remains harmless. If you were getting a short list back from one of these entities, you’ll now get all of them, so take a look anywhere you render or loop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop over the results without setting your own limit. Custom entities backed by a non-paginated REST route should declare supportsPagination: false.

References:

• getPostTypes() limited to 10
• Core Data: Fix incorrect pagination for non-paginated entities

Starting in WordPress 7.1, the @wordpress/nux package becomes a no-op compatibility package.

The package has been deprecated since WordPress 5.4. It remains available so existing imports and script dependencies do not break, but it no longer displays tips or guides.

If you still rely on NUX for onboarding, migrate to the Guide component from @wordpress/components instead.

References:

• Make @wordpress/nux a no-op compatibility package

The @wordpress/reusable-blocks package components and data APIs will log deprecation warnings starting from WordPress 7.1.

The package only exposed experimental APIs, and it hasn’t been used by the core since 2023. If your code needs to fetch or update Synced Patterns (formerly known as Reusable Blocks) on the client side, use the standard core entity methods.

This deprecation prepares the packages for a no-op backward compatibility update, similar to @wordpress/nux.

References:

• Deprecate @wordpress/reusable-blocks public APIs