wp-editor-components

WordPress Editor Components

Use public WordPress components for editor/admin application UI, but keep form state, persistence, authorization, and errors in your own explicit data flow. Component visibility and disabled state are never server-side access control.

Load the package correctly

When using @wordpress/scripts, import packages normally and consume the generated .asset.php file so wp-components, wp-element, wp-i18n, and other dependencies are declared automatically. Do not bundle a second React or reach through window.wp.components private properties to bypass the build.

Load component CSS in the target document. WordPress 7.1's post-editor canvas is always iframed, so distinguish shell components from block content styles. If custom UI uses @wordpress/theme or --wpds-* tokens, declare the matching wp-theme script/style dependency; the two registries are independent.

Build accessible controlled controls

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

<TextControl
	label={ __( 'API label', 'acme' ) }
	value={ label }
	onChange={ setLabel }
	help={ error || __( 'Shown to editors.', 'acme' ) }
/>;

Keep a stable controlled value and provide real labels, help/error association, keyboard behavior, focus restoration, and loading feedback. Do not scrape a component's generated DOM, class names, or Emotion identifiers. Use documented props and composition.

WordPress 7.1 form-control sizing

Affected form controls now use a 40px default unconditionally. Remove __next40pxDefaultSize; it has no runtime effect, and false does not restore 36px. On BorderBoxControl, BorderControl, FontSizePicker, and ToggleGroupControl, the old size prop is also deprecated and ineffective.

This rollout does not include Button; do not mechanically remove a Button opt-in without checking its current contract. Audit surrounding fixed heights, grid rows, modal footers, and custom CSS instead of forcing old internal dimensions back onto the component.