How to Adapt Your Plugins for Editor Component Updates in WordPress 7.1

Introduction to WordPress 7.1 Component Modernization

WordPress 7.1 introduces significant updates to the @wordpress/components and @wordpress/block-editor packages. These changes represent a major step forward in standardizing the block editor’s user interface, improving accessibility, and cleaning up legacy APIs. Developers maintaining plugins, themes, or custom Gutenberg blocks must adapt to these updates to ensure their custom interfaces remain visually consistent and free of runtime errors.

This guide explores the transition to an unconditional 40px default form control size, the ongoing migration from Emotion to SCSS modules, and the removal of deprecated APIs like the legacy Navigation component.

The Unconditional 40px Form Control Standard

Historically, form controls in the WordPress block editor rendered at a default height of 36px. To align with modern accessibility standards and improve touch targets, the WordPress contributor team initiated a transition to a 40px default height.

This rollout began in WordPress 6.7 with the introduction of the opt-in __next40pxDefaultSize prop. In WordPress 6.8, a soft deprecation phase was introduced, where components that had not opted in logged warnings to the browser console. With the release of WordPress 7.1, this transition is complete. Form controls now unconditionally render at a 40px height by default. The __next40pxDefaultSize prop is officially deprecated, has no runtime effect, and can be safely removed from your codebase.

Affected Form Components and Deprecated Props

The transition to the 40px height standard affects a wide array of input, selection, and configuration controls across both the @wordpress/components and @wordpress/block-editor packages.

The following components are affected:

• @wordpress/components: BorderBoxControl, BorderControl, BoxControl, ComboboxControl, CustomSelectControl, FontSizePicker, FormFileUpload, FormTokenField, FocalPointPicker, InputControl, NumberControl, QueryControls, Radio, RangeControl, SearchControl, SelectControl, TextControl, ToggleGroupControl, TreeSelect, and UnitControl.
• @wordpress/block-editor: FontAppearanceControl, FontFamilyControl, LetterSpacingControl, and LineHeightControl.

Important Exception: The Button component is not included in this rollout. It still utilizes its own opt-in prop and remains unchanged in WordPress 7.1.

In addition to the removal of __next40pxDefaultSize, the size prop has been deprecated and rendered ineffective on the following components:

• BorderBoxControl
• BorderControl
• FontSizePicker
• ToggleGroupControl

If you previously passed size="__unstable-large" to these components simply to force a 40px height, you should remove this prop.

Migrating from Emotion to SCSS Modules

A major architectural shift is underway within the @wordpress/components package: the migration of component styling from the Emotion CSS-in-JS library to static SCSS modules. This change aims to improve editor performance by reducing runtime style evaluation overhead and simplifying the build pipeline.

While most consumers who rely on default styles will not notice any changes, developers who use Emotion to style or extend core components must adapt to two critical migration details. This particularly affects the following components:

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

As the migration continues, more components will be refactored to SCSS modules.

Handling the Legacy css Prop and Style Overrides

With the removal of Emotion from the View component, the legacy css prop is no longer supported for rendering styles. Although the prop is retained in the TypeScript definitions for backward compatibility, it is now a complete “no-op” (no operation) at runtime.

To migrate, you must replace the css prop with standard styling mechanisms:

• Use the style prop for dynamic inline styles.
• Use the className prop for class-based styling.

Resolving Cascade Issues with Emotion cx()

When styling components that have migrated away from Emotion, you may encounter issues with CSS cascade order if you rely on Emotion’s cx() utility to merge separate css() style fragments.

Because the View component no longer renders through Emotion, passing separate style fragments to cx() can alter the intended override order of shorthand/longhand properties or nested selectors. To preserve the correct CSS cascade, you must compose source-order-dependent fragments into a single css() call before passing them to cx().

Code Comparison: Adapting to the Emotion Migration

Here is how to refactor your code to handle the styling changes safely.

Example 1: Replacing the legacy css prop on the View component

// Before (WP 7.0 and earlier)
import { View } from '@wordpress/components';
import { css } from '@emotion/react';

const customStyles = css`
  background: #f0f0f0;
  padding: 16px;
`;

const MyComponent = () => (
  <View css={ customStyles }>Content</View>
);

// After (WP 7.1)
import { View } from '@wordpress/components';

const MyComponent = () => (
  <View className="my-custom-view-class">Content</View>
);

Example 2: Fixing the cx() cascade order

// Before (Fragile cascade order in WP 7.1)
const classes = cx(
  css( baseStyles ),
  condition && css( overrideStyles ),
  className
);

// After (Preserved cascade order in WP 7.1)
const classes = cx(
  css( baseStyles, condition && overrideStyles ),
  className
);

This updated pattern keeps shorthand/longhand overrides and nested-selector overrides in one generated class, preserving the intended cascade order.

Complete Removal of the Legacy Navigation Component

WordPress 7.1 officially removes the deprecated Navigation component and its associated subcomponents from @wordpress/components. This component was soft-deprecated in WordPress 6.8.

If your custom blocks or plugins still rely on Navigation, you must migrate to the modern Navigator component. The Navigator API offers a more robust, flexible, and accessible approach to handling nested navigation screens within sidebar panels and custom editor interfaces.

Removal of __experimentalApplyValueToSides

Another cleanup task completed in WordPress 7.1 is the removal of the __experimentalApplyValueToSides utility from @wordpress/components. This utility, which was deprecated in WordPress 6.8, is no longer available.

Fortunately, this removal does not affect the BoxControl component itself. BoxControl has been refactored to handle its side-value calculations internally, meaning developers using <BoxControl /> do not need to make any changes unless they were directly importing and calling the experimental utility in custom code.

Actionable Migration Checklist for WordPress 7.1

To prepare your plugins and custom block libraries for WordPress 7.1, follow this checklist:

1. Search your codebase for __next40pxDefaultSize and delete all instances from form controls.
2. Identify any usage of size="__unstable-large" on BorderBoxControl, BorderControl, FontSizePicker, and ToggleGroupControl, and remove them.
3. Audit your usage of the View component and replace any instances of the css prop with className or style.
4. Review your custom Emotion styles. If you use cx() to merge style fragments for Divider, Surface, Truncate, View, Flex, or Spacer, ensure they are composed within a single css() call.
5. Replace any remaining imports of the legacy Navigation component with Navigator.
6. Remove any imports or references to the __experimentalApplyValueToSides utility.

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