WordPress 7.1 Makes the 40px Component Default Permanent

I have been building admin screens on top of @wordpress/components since long before there was a “components” package. Every time the design system changes underneath me, I get the same question from clients: is this the one that breaks my plugin.

This week is one of those weeks, but for once the answer is boring. The 40 pixel control height that WordPress has been slowly walking toward since 6.4 is finally becoming the permanent default in 7.1. If your code opted in years ago, nothing changes. If it never did, you will notice — and you have exactly one Beta cycle to fix it before the API surface pins.

Here is what actually landed, why the release squad handled it this way, and the audit I would run on any client codebase this week.

What is actually new

The __next40pxDefaultSize prop is now hard-deprecated across a first wave of core components. The July 2026 developer roundup by Ryan Welcher on the WordPress Developer Blog is the clearest summary and lists the ten components that shipped the change in Gutenberg 23.5, which is the plugin release that backports into WordPress 7.1: TextControl, BoxControl, BorderControl, FontSizePicker, RangeControl, ComboboxControl, ToggleGroupControl, UnitControl, FormTokenField, and CustomSelectControl.

What “hard-deprecated” means here is precise. The prop is not removed from the type signature — passing it still compiles, and existing calls will not throw. But the runtime handler is gone. The 40 pixel size is now baked into the default styles, and the prop is a no-op. The TextControl change is Gutenberg PR #79386 by mirka, merged on June 23, 2026 — the PR description states plainly that the prop “no longer has any functional effect” and is replaced with a deprecated type stub for external compatibility. The BoxControl equivalent is PR #79419, merged the next day, which removes the prop from the public API of that component while still passing it internally to the embedded UnitControl and RangeControl instances until those primitives finish their own deprecation cycles.

This has been a long walk. The 40 pixel default was announced in the WordPress 6.4 components dev note in October 2023, wrapped in the temporary opt-in prop so that themes and plugins could switch on their own schedule. The original tracking issue laid out the plan: introduce the prop, get everything migrated, then flip the default and retire the flag. Consumers who never opted in stayed on the 36 pixel default and got soft deprecation warnings after 6.7. The 7.1 wave is the last stop before the prop becomes truly meaningless.

Two supporting mechanics matter. First, the components-no-missing-40px-size-prop ESLint rule in @wordpress/eslint-plugin was already flagging any component usage that did not pass the opt-in flag. If your build was clean under the WordPress preset, you are almost certainly done. Second, the trunk of Gutenberg pins to the wp/7.1 branch at Beta 1, which shipped on July 15, 2026 per the 7.1 release party schedule. The API surface for 19 August is exactly what is in Beta 1 today. No more soft-deprecation-to-hard-deprecation surprises for this component set this cycle.

Why it matters for WordPress and WooCommerce people

Most agency plugins render at least one settings screen and most of those screens are built on the same handful of controls. TextControl is the one you cannot avoid. RangeControl and UnitControl show up in nearly every “spacing”, “font size”, or “breakpoint” panel. SelectControl variants and ComboboxControl own every dropdown that talks to the REST API. If you built a plugin in 2022 or 2023 and never touched the UI since, the layout you tested against was 36 pixels tall. Under 7.1 it is 40. Four pixels do not sound like much until they run into a two-column grid with tight vertical rhythm and a Save button whose Y-coordinate is pinned by CSS.

WooCommerce is on the same clock. Extension teams that render inside WC_Settings_Page, the new Settings UI framework, or the Payments/Shipping method screens all consume the same components. The Woo 11.0 pre-release notes already flagged a separate ESLint rule change (import/order replacing the deprecated dependency-group rule) that breaks CI for teams still pinned to the old config. Two lint-rule migrations plus a live component default shift is the sort of small pile that eats a Monday morning if nobody warned you.

The wider signal is that Gutenberg’s design-system layer is finally acting like a design system. The design system theming merge proposal we covered on July 8 lands the token pipeline. This 40 pixel default flips the last opt-in switch on the sizing side. Together they are what plugin authors have been asking for since 6.4: predictable defaults, one theming layer, one stable component API to build against.

What I would do (or not do) about it

Run four passes on any plugin or theme that renders admin UI, in this order, on staging with WordPress 7.1 Beta 1 and Gutenberg 23.5 installed side by side.

1. Grep for the prop. Search the codebase for __next40pxDefaultSize. Every hit is safe to leave in place today — the prop is still typed and still valid — but each one is future dead code. Plan to remove them in the same PR that bumps your minimum-WordPress to 7.1.
2. Run the ESLint rule against your codebase. Add @wordpress/eslint-plugin to devDependencies if it is not already there and enable the recommended preset. Any component that renders a control from the affected list and does not know about the 40 pixel default gets flagged. Fix by removing the prop where present and by re-checking layout for anything that did not have it.
3. Visual pass on every settings screen. This is the one nobody wants to do and the one that catches every bug. Open each admin page in the plugin, at 1x and 2x, and look at whether the added four pixels per control break your grid. Common failure modes: sidebar panels that clip, sticky Save buttons that overlap the last row, tables with mixed control heights, and two-column layouts where labels stopped aligning with inputs.
4. Deprecation-warning audit. Enable SCRIPT_DEBUG, open the browser console on every editor and admin screen you own, and copy anything logged by the Gutenberg deprecation runtime. The stack trace names the component and the calling file. Fix or file, do not ignore.

Two things I would not do. First, do not attempt to force the 36 pixel size back with CSS overrides. It will work in 7.1, it will fight you in 7.2, and it defeats the accessibility argument that got the 40 pixel default over the line in the first place — touch targets that meet WCAG guidance without the user having to squint. Second, do not run this audit for the first time in production on 19 August. The point of Beta 1 pinning the API surface is that you have four weeks to test on staging with the exact code that will ship. Use them.

The nice part of a slow-rolled deprecation is that it stops being news by the time it lands. Everyone who opted in early is done. Everyone who did not has one Beta cycle and a clear PR list to work from. That is what governance is meant to look like.