WordPress 7.1 Editor Components Guide: Upgrading Form Controls, Emotion Styles, and Deprecated APIs

Introduction to WordPress 7.1 Editor Component Updates

With the release of WordPress 7.1, the block editor ecosystem continues to refine its user interface, performance, and developer experience. The @wordpress/components and @wordpress/block-editor packages have received major updates aimed at standardization and code cleanup. This release marks the final stage of several multi-version deprecation cycles, transitioning experimental APIs to stable standards and refactoring internal styling architectures.

For WordPress developers, these changes require active codebase audits. Key updates include the unconditional enforcement of 40px heights for form controls, an architectural shift away from Emotion-based CSS-in-JS styling toward SCSS modules, and the complete removal of deprecated components like the legacy Navigation component and experimental layout utilities. Understanding these changes is essential to prevent layout breakage and runtime errors in custom blocks, plugins, and editor extensions.

Unconditional 40px Default Height for Form Controls

Starting in WordPress 7.1, form controls within the @wordpress/components package use a 40px default height unconditionally. This change completes a rollout strategy that began in WordPress 6.7 to improve accessibility, touch-target sizing, and visual consistency across the block editor interface.

Previously, the 40px height was an opt-in feature controlled by the __next40pxDefaultSize prop. This prop was introduced in WordPress 6.7 to allow developers to test and adapt their custom interfaces. In WordPress 6.8, the prop was soft-deprecated, and components that had not opted in began logging console warnings. In WordPress 7.1, the transition is complete:

• No Runtime Effect: The __next40pxDefaultSize prop is no longer needed and has no runtime effect when passed.
• No Opt-Out: Passing __next40pxDefaultSize={ false } will no longer revert the component to the legacy 36px height.
• Size Prop Deprecation: On specific components—namely BorderBoxControl, BorderControl, FontSizePicker, and ToggleGroupControl—the size prop is deprecated and has no effect.

Developers must audit their custom blocks and inspector controls to remove these obsolete props. If you previously used size="__unstable-large" solely to force a 40px height on these components, that prop should also be removed.

Complete List of Affected Form Control Components

The 40px default height rollout applies broadly across the WordPress editor component library. The following components in the @wordpress/components package now render at 40px by default:

• BorderBoxControl
• BorderControl
• BoxControl
• ComboboxControl
• CustomSelectControl
• FontSizePicker
• FormFileUpload
• FormTokenField
• FocalPointPicker
• InputControl
• NumberControl
• QueryControls
• Radio
• RangeControl
• SearchControl
• SelectControl
• TextControl
• ToggleGroupControl
• TreeSelect
• UnitControl

Additionally, several typography-related controls within the @wordpress/block-editor package are affected:

• FontAppearanceControl
• FontFamilyControl
• LetterSpacingControl
• LineHeightControl

Important Limitation: This update covers form controls only. The Button component is not included in this rollout; it continues to use its own opt-in prop and remains unchanged in WordPress 7.1.

Step-by-Step Refactoring for the 40px Height Standard

Refactoring your components for WordPress 7.1 is straightforward. You should search your codebase for instances of __next40pxDefaultSize and remove them. Below is an example of a typical text input control refactoring.

Before WordPress 7.1 (Legacy Code):

import { TextControl } from '@wordpress/components';

const MyPluginSettings = ( { email, setEmail } ) => (
	<TextControl
		label="Notification Email"
		value={ email }
		onChange={ setEmail }
		__next40pxDefaultSize={ true }
	/>
);

After WordPress 7.1 (Clean Code):

import { TextControl } from '@wordpress/components';

const MyPluginSettings = ( { email, setEmail } ) => (
	<TextControl
		label="Notification Email"
		value={ email }
		onChange={ setEmail }
	/>
);

If you have custom CSS rules targeting these inputs based on the assumption of a 36px height, you should review your layout alignments. The 4px height increase may affect vertical spacing in dense, custom-styled sidebars.

Emotion to SCSS Modules Migration: What Developers Need to Know

A long-running architectural migration has kickstarted in the @wordpress/components package. The WordPress core team is refactoring all components to replace Emotion-based CSS-in-JS styles with static SCSS modules. This change significantly improves editor performance by reducing runtime style evaluation and minimizing the JavaScript bundle size.

While this migration is mostly internal, it introduces breaking changes for developers who rely on Emotion-specific APIs or write custom styles that target Emotion-generated class names. If your plugin or theme styles editor components using Emotion, you must adapt your code to accommodate two key migration details.

First, the View component still accepts the legacy css prop for TypeScript and type compatibility, but it is now a no-op (no operation) at runtime. Passing styles via the css prop to View will have no visual effect. Instead, you must use the standard style prop for inline styles or the className prop for CSS-based styling.

Second, when using Emotion’s cx() utility with css() style fragments, you must compose source-order-dependent fragments into a single css() call before passing them to cx(). Because the View component no longer renders through Emotion, passing separate fragments to cx() can alter the CSS cascade and override order.

Handling Style Composition and the Legacy css Prop

To ensure your custom styles cascade correctly during the SCSS migration, you must adjust how you compose dynamic styles. Consider the following examples demonstrating how to refactor your style composition.

Incorrect Style Composition (May break override order):

import { cx, css } from '@emotion/css';
import { View } from '@wordpress/components';

const MyStyledComponent = ( { isUrgent, className } ) => {
	const baseStyles = css`color: blue; font-size: 14px;`;
	const urgentStyles = css`color: red; font-weight: bold;`;

	// Passing separate fragments to cx() can cause unpredictable overrides in WP 7.1
	return (
		<View className={ cx( baseStyles, isUrgent && urgentStyles, className ) } />
	);
};

Correct Style Composition (Preserves cascade order):

import { cx, css } from '@emotion/css';
import { View } from '@wordpress/components';

const MyStyledComponent = ( { isUrgent, className } ) => {
	const baseStyles = { color: 'blue', fontSize: '14px' };
	const urgentStyles = { color: 'red', fontWeight: 'bold' };

	// Compose source-order-dependent fragments into a single css() call
	const composedClasses = cx(
		css( baseStyles, isUrgent && urgentStyles ),
		className
	);

	return (
		<View className={ composedClasses } />
	);
};

By nesting the conditional styles inside a single css() call, Emotion compiles them into a single generated class. This guarantees that shorthand/longhand overrides and nested-selector overrides behave exactly as intended. The components currently affected by this migration are:

• Divider
• Surface
• Truncate
• View
• Flex
• Spacer

This list is expected to grow as the core team continues refactoring components. You can track the progress of this migration via GitHub issue #66806.

Deprecated Component Removals: Navigation and Experimental Utilities

WordPress 7.1 cleans up the codebase by removing components and utilities that have undergone their full deprecation lifecycle since WordPress 6.8.

Removal of the Navigation Component

The legacy Navigation component and its associated subcomponents have been completely removed from @wordpress/components (#78529). This component was soft-deprecated in WordPress 6.8. If your plugin still imports Navigation, it will throw a runtime error in WordPress 7.1.

Developers must migrate to the modern Navigator component, which provides a more robust, accessible, and flexible API for handling multi-step screen navigation within editor sidebars and modals.

Removal of __experimentalApplyValueToSides

The experimental layout utility __experimentalApplyValueToSides has been removed from @wordpress/components (#78528). This utility was used to parse and apply spacing values (like margin or padding) to individual sides of a block. It has been deprecated since WordPress 6.8.

Note that the BoxControl component itself, which internally relied on similar logic, is entirely unaffected by this removal. If you were importing this experimental utility directly in custom block controls, you must replace it with custom CSS or alternative utility functions.

Practical Migration Checklist for WordPress 7.1

To ensure your plugins and themes are fully compatible with WordPress 7.1, follow this practical migration checklist:

1. Audit Form Controls: Search your codebase for __next40pxDefaultSize and delete the prop from all component instances.
2. Remove Deprecated Size Props: Locate any usage of size="__unstable-large" on BorderBoxControl, BorderControl, FontSizePicker, and ToggleGroupControl, and remove them.
3. Verify Layout Spacing: Test your custom sidebar panels and settings pages to ensure the unconditional 40px height does not cause layout truncation or unwanted scrollbars.
4. Refactor View Components: Ensure no custom code passes the css prop directly to the View component. Convert these to style or className.
5. Update Emotion Composition: Check your usage of Emotion’s cx() utility. Ensure that multiple style objects are composed inside a single css() call when order-dependent overrides are required.
6. Replace Navigation: Replace any remaining instances of the legacy Navigation component with the stable Navigator component.
7. Eliminate Experimental Utilities: Remove any imports of __experimentalApplyValueToSides and implement standard CSS properties or custom helper functions instead.

Primary reference: Review the original announcement for exact release details. This article is an independent explanation and does not reproduce the source text.