ByWordPress 7.1 breaking changes affect any plugin or theme that touches the block editor’s form controls, the widget dashboard, or the new Abilities API, and most of them trace back to a single hard deprecation: the __next40pxDefaultSize prop that used to opt components into the larger 40px control size is now a no-op, because 40px is the permanent default. If your admin screens or custom blocks pass that prop, or relied on the old smaller size without it, you will see visual shifts and console warnings the moment a site updates.
This guide walks through exactly what changed, why WordPress core made these calls, and the fixes to ship before your users update. It is written for plugin authors, theme developers, and freelancers who maintain client sites, not for readers who just want a feature tour — for that, see our WordPress 7.1 new features guide.
What Are the WordPress 7.1 Breaking Changes, Exactly?
The WordPress 7.1 breaking changes are a coordinated wave of hard deprecations across roughly 20 components in the @wordpress/components package, starting with TextControl and continuing through BoxControl, BorderControl, FontSizePicker, RangeControl, ComboboxControl, ToggleGroupControl, UnitControl, FormTokenField, and CustomSelectControl. According to the WordPress core team’s July 2026 announcement, the rollout began on June 23 and reached hard-deprecation status for the WordPress 7.1 release that shipped August 19, 2026, at WordCamp US in Phoenix.
On top of the component deprecations, WordPress 7.1 ships more than 310 Core Trac tickets, including over 100 enhancements and more than 180 bug fixes, per the official developer blog. Most of those tickets are backward compatible. The ones that are not fall into three buckets: form control sizing, widget dashboard primitives, and Notes API surface changes. Each one is narrow, but if your plugin touches any of them, the breakage is immediate and visible on the admin screen.
It helps to be precise about who is affected. Site owners running a stock theme and mainstream plugins from the WordPress.org directory will likely notice nothing at all, since most popular plugin authors patch against core deprecation waves before they ship. The people who need this guide are plugin and theme developers, agencies maintaining bespoke admin screens for clients, and anyone who registered a custom widget, block, or ability against an earlier WordPress version and hasn’t re-tested since.
Why Did WordPress Hard-Deprecate the 40px Component Default?
WordPress hard-deprecated the 40px default because the smaller, legacy control size was always meant to be temporary. Since WordPress 6.8, components like TextControl and SelectControl shipped with an opt-in __next40pxDefaultSize prop that let developers preview the larger, more touch-friendly 40px sizing ahead of time. WordPress 7.1 finishes that transition: the prop becomes a no-op, and every affected component renders at 40px whether or not you pass it.
If your plugin still passes __next40pxDefaultSize, nothing crashes — the prop is silently ignored, and you’ll see a deprecation notice in the browser console when SCRIPT_DEBUG is on. The real risk is layout: custom admin screens built around the old, smaller 32px controls can suddenly look cramped or misaligned once every field jumps to 40px. Settings pages with dense grids of text fields are the most common casualties.
The fix is mechanical. Search your plugin for every instance of __next40pxDefaultSize and remove the prop entirely — it does nothing now, so keeping it just adds noise. Then open each affected admin screen at 40px sizing and check spacing, alignment, and any hardcoded pixel heights you may have set around those controls in custom CSS.
How Do the Widget Dashboard Changes Affect Your Plugin?
The widget dashboard changes affect any plugin that registers custom widgets or reads widget data through the REST API. WordPress 7.1 moves widget primitives to a script module and introduces typed, declarative widget definitions backed by a field type registry. The new WidgetAttributeField gives widgets typed attribute schemas instead of loosely typed arrays, and the widget category is now exposed through both the build pipeline and the REST API.
For most site owners this is invisible. For plugin developers who register legacy widgets or query /wp/v2/widgets directly, two things matter. First, widget attribute validation is now schema-driven, so a widget that saved loosely typed data before may need its attributes redeclared to pass validation. Second, code that assumed an untyped attributes bag should be updated to read the new field type registry rather than guessing types at runtime.
Test this by activating your plugin on a fresh WordPress 7.1 install, adding one of each widget type it registers to a widget area, saving, and reloading the page. If the widget’s saved values disappear or reset to defaults, its attribute schema needs updating for the new field type registry.
What Should You Check in the Abilities API Before Updating?
You should check that any ability your plugin registers still declares an explicit input and output JSON schema, because WordPress 7.1 is the first core release to ship the Abilities API as a stable feature rather than a plugin-only experiment. Abilities registered against early, pre-release versions of the API sometimes relied on implicit typing that the stabilized API no longer accepts silently. We cover the full registration pattern, permission callbacks, and REST exposure in our dedicated WordPress Abilities API guide, so this section only covers what changed for 7.1 specifically.
The practical check is quick: run wp ability list if you have WP-CLI access, or query the abilities REST endpoint, and confirm every ability your plugin registers still appears with its expected schema after updating to 7.1. If one silently vanishes, it usually means a registration call is firing before the wp_abilities_api_init hook fires, which core is now stricter about enforcing.
WordPress 7.1 Breaking Changes: Quick Fix Checklist
Use this table as a fast reference while you audit a plugin or theme. Each row maps a specific WordPress 7.1 change to the concrete fix, so you can work through it top to bottom instead of re-reading the full explanation for every item.
| What Changed | Where You’ll See It | The Fix |
|---|---|---|
| __next40pxDefaultSize hard-deprecated | Custom admin screens, settings pages | Remove the prop; test layout at 40px |
| ~20 components affected (TextControl, BoxControl, RangeControl, etc.) | Any custom block or admin UI using these controls | Audit each component’s spacing and alignment |
| Widget primitives moved to script module | Legacy widgets, /wp/v2/widgets REST calls | Redeclare attribute schemas with WidgetAttributeField |
| Abilities API stabilized | Plugins registering custom abilities | Confirm schemas via wp ability list or REST |
| Notes API gets @mentions and revision links | Editorial workflow plugins reading Notes data | Re-check any code parsing Notes REST responses |
How Do You Test a Plugin for WordPress 7.1 Compatibility?
Testing for WordPress 7.1 compatibility takes four steps, and skipping the staging step is the single most common reason developers get support tickets after a core update ships.
- Spin up a staging copy of the site on WordPress 7.1 with
SCRIPT_DEBUGenabled so deprecation notices print to the browser console instead of failing silently. - Search your codebase for
__next40pxDefaultSize,wp/v2/widgets, and any custom ability registration calls, and open each affected admin screen manually. - Compare screenshots of key admin screens before and after the update at the same browser width, since 40px sizing shifts vertical rhythm more than horizontal layout.
- Run your plugin’s existing PHPUnit or Playwright suite against the WordPress 7.1 test environment before tagging a compatible release in your plugin’s readme.txt.
If your site is also due for a performance pass while you’re in staging, our WordPress speed guide covers caching and asset changes that pair well with a major core update, since both often touch the same admin and front-end scripts.
What Changed in Notes and DataViews in WordPress 7.1?
Notes and DataViews both picked up meaningful additions in WordPress 7.1 without breaking their existing APIs, which makes them lower risk than the component and widget changes above. Notes gained email notifications for @mentions and shareable revision links, so any plugin that reads or displays Notes data through the REST API should double check it handles the new mention and link fields gracefully rather than dropping them.
DataViews and its View Config system, which power list-style admin screens like the Pages and Posts list tables, received refinements to filtering and layout configuration. These are additive rather than breaking, but if you extended a DataViews-based screen with custom columns or filters, re-test that UI specifically, since View Config’s shape has shifted slightly between 7.0 and 7.1 even though the public API contract held.
What Do the Other WordPress 7.1 Field Guide Areas Change?
The official WordPress 7.1 Field Guide covers Media, Accessibility, Global Styles, the SVG Icon API, the persistent admin bar, and a batch of external library updates alongside the component and widget changes covered above. Most of these are additive, but two are worth a quick look even if you skip the rest. The SVG Icon API standardizes how plugins register custom icons for the block inserter and toolbar; if you were hacking icons in through raw SVG markup before, migrating to the registered API keeps you compatible as core continues consolidating icon handling.
The persistent admin bar is a UI change, not an API break, but it can affect plugins that inject custom markup into the classic admin bar or that measure viewport height assuming the bar can scroll out of view. If your plugin does either, check it on a long admin page like Pages or Posts with many rows, since the bar’s new persistent behavior changes how much vertical space is actually available.
What Do WordPress 7.1 Deprecation Warnings Look Like in the Console?
WordPress 7.1 deprecation warnings for the component changes appear in the browser console only when SCRIPT_DEBUG is enabled, which is exactly why so many developers miss them on production sites where debug mode is off by default. A typical warning reads along the lines of: “The __next40pxDefaultSize prop is deprecated since version 7.1 and has no effect. The 40px size is now the default.” This message doesn’t stop the page from working, so it’s easy to dismiss, but it’s the clearest signal that a specific call site needs cleanup.
To catch these systematically rather than by accident, enable SCRIPT_DEBUG and WP_DEBUG_LOG on a staging copy, then click through every admin screen your plugin adds or modifies while keeping the browser console open. Log each warning with the file and line it points to, fix the prop usage, and re-test. This is faster than grepping your codebase blind, because the console tells you exactly which rendered component triggered the warning, including ones loaded indirectly through a third-party field library.
How Should Agencies Roll Out WordPress 7.1 Across Client Sites?
Agencies managing dozens of client sites should treat the WordPress 7.1 breaking changes as a staged rollout rather than a single update event, because the risk isn’t uniform across a portfolio — it concentrates in sites with heavily customized admin screens or older, less-maintained plugins.
- Group client sites into tiers: stock-theme sites with mainstream plugins, sites with one or two custom plugins, and sites with heavily bespoke admin functionality.
- Update the lowest-risk tier first and monitor support tickets for 48 to 72 hours before moving to the next tier.
- For the highest-risk tier, clone the site to staging, run the four-step compatibility test above, and only then schedule a maintenance window for production.
- Keep a shared changelog of which custom plugins have been patched for the June 23 deprecation wave so the check isn’t repeated from scratch for every client running the same plugin.
This tiered approach turns a single risky update event into a controlled rollout, which matters more for WordPress 7.1 than for a typical point release because the component deprecations are visual and immediately noticeable to end clients, even when nothing is actually broken under the hood.
Should You Update to WordPress 7.1 Right Away?
Update to WordPress 7.1 on a staging site first if you maintain plugins, themes, or client sites with custom admin screens; update production immediately only if you run a stock theme with no custom admin UI and a short list of well-maintained plugins. The security and bug-fix content in 7.1 is worth having quickly — our WordPress 7.0.4 security update guide covers the release that preceded it — but the component deprecations mean “update everywhere immediately” is the wrong default for anyone shipping custom code.
A reasonable rollout order: update your own staging and development environments first, then any sites where you personally maintain custom plugins, then client sites after you’ve confirmed their specific plugin stack against the checklist table above. Sites running only well-known, actively maintained plugins from the WordPress.org directory typically see zero visible breakage, because most plugin authors have already patched against the June 23 deprecation wave.
Frequently Asked Questions
Will WordPress 7.1 break my site if I don’t touch custom code?
No. If you don’t run custom plugins, custom blocks, or a custom admin theme, WordPress 7.1’s breaking changes won’t affect you, because they target component props and REST behavior that only developer-facing code interacts with directly.
Does removing __next40pxDefaultSize require a version bump in my plugin?
It’s good practice to bump at least a patch version, since removing a now-dead prop and re-testing layout at 40px is a real code change, even though the prop itself did nothing once WordPress 7.1 stabilized 40px as the default.
How long will the __next40pxDefaultSize prop keep working without errors?
The prop is a no-op as of WordPress 7.1, meaning it won’t throw errors, but WordPress core has a pattern of removing hard-deprecated props entirely a few major versions later, so plan to clean it up rather than leaving it indefinitely.
Do the widget dashboard changes affect the block-based widgets editor only?
No. The script-module move and typed attribute schemas affect any code path that reads or writes widget data, including classic widgets accessed through the REST API, not only the block-based widgets screen in wp-admin.
Where can I read the official list of WordPress 7.1 breaking changes?
The most reliable sources are the Make WordPress Core blog’s post on editor component updates and the official WordPress developer blog’s monthly roundup, both of which are linked as sources in this guide.
Should I wait for WordPress 7.1.1 before updating client sites?
Waiting a week or two for an early point release is reasonable caution for agencies managing many client sites, but it should not replace testing — most WordPress 7.1 breaking changes are in plugin and theme code paths that a point release won’t touch, since they’re by-design deprecations, not bugs.
WordPress 7.1 breaking changes are narrow but predictable: form control sizing, widget attribute schemas, and Abilities API registration are the three places to check before you update a site running custom code. Work through the checklist table, test on staging first, and most plugins will clear WordPress 7.1 without any visible disruption to editors or site visitors. The teams that get burned are almost always the ones that skip staging entirely and update production the same day a major release ships, not the ones whose code happens to touch a deprecated prop.
Sources: Make WordPress Core, “Editor components updates in WordPress 7.1,” July 2026; WordPress Developer Blog, “What’s new for developers? (August 2026)”.
Subscribe for Newsletter
