AdminMajor developer features and breaking changes — expanded developer reference
This WordPress 7.1 for developers guide outlines the major developer features and breaking changes in WordPress 7.1 and is published during the Release Candidate phase to help inform WordPress extenders, Core developers, and everyone else interested in the latest WordPress development. WordPress 7.1 is scheduled for release on August 19, 2026, at WordCamp US in Phoenix.
There are more than 310 Core Trac tickets included in WordPress 7.1, over 100 of which are enhancements and feature requests, and more than 180 bug fixes. This release includes 40+ tickets focused on the Editor, with the most attention going to accessibility (46), UI (40), and administration (28) focuses. On the block editor side, roughly 600 enhancements and more than 630 bug fixes arrive from the bundled Gutenberg releases (22.7 through 23.6).
A quick search of the diff between 7.0.2 and the 7.1 branch reveals 20 new hooks (19 filters and 1 action), 1,480 total files changed, with 88,163 insertions and 18,601 deletions. Kudos to everyone who contributed to the 7.1 release, in any way, shape, or form.
How to use this guide. Each section below summarises a feature area and then goes into the developer-facing detail: new APIs, breaking changes, the filters and hooks you can rely on, and the tickets behind the work. Code samples are drawn from the official developer notes. Where a section links to a full dev note, that note remains the canonical, most detailed reference.
1. Media
WordPress 7.1 continues the modernisation of media workflows across the editor, REST API, and Media Library. The release introduces client-side processing capabilities, improves the handling and registration of image sizes, and changes the default Media Library browsing experience.
Client-side media processing
WordPress 7.1 ships client-side media processing — image compression, resizing, format conversion, rotation, and thumbnail generation performed directly in the browser using WebAssembly instead of on the server. It is enabled by default in supporting browsers, and falls back to server-side processing transparently everywhere else.
Traditionally an uploaded image is sent to the server, where PHP (via GD or Imagick) generates every registered sub-size, applies format conversion and EXIF rotation, and scales oversized images — work bounded by PHP memory, server CPU, and the installed image library. In 7.1 that work moves to the browser using wasm-vips, a WebAssembly build of the high-performance libvips library. All processed images, including thumbnails, are then uploaded and stored. Afterward a finalize step applies the wp_generate_attachment_metadata filter with context ‘update’ so plugins still see the full sub-sizes metadata.
Key benefits
- Consistent, high-quality output. Every user gets libvips-powered processing regardless of whether the host has GD or Imagick, or which version.
- Smaller files for visitors. libvips out-compresses GD and Imagick — JPEGs shrink roughly 15% with MozJPEG-like encoding.
- No more PHP memory failures. Large-image processing that would blow PHP’s memory limit now runs in the browser’s memory space.
- Reduced server load. Sub-size generation — a leading cause of timeouts on shared hosting — is offloaded to the user’s device.
- iPhone photos just work. HEIC/HEIF images are decoded in the browser and uploaded as web-ready JPEG, with the original kept as a companion file. HEIC decode works in Chromium browsers on macOS/Windows and in Safari on macOS.
- AVIF without server support. AVIF can be decoded client-side even on hosts whose PHP image editor lacks AVIF support.
- Animated GIFs become efficient video. Opaque animated GIFs are converted in the browser to a companion MP4/WebM that autoplays, loops, and is muted — far fewer bytes, same feel. The attachment stays a GIF; the swap is reversible; transparent GIFs are left alone.
- More resilient uploads. Each sub-size is an independent request with automatic retry and exponential backoff; uploads pause offline and resume when back online.
Architecture
The pipeline is orchestrated by a set of packages, with a small PHP surface to gate the feature and extend the REST API:
- @wordpress/upload-media — manages the upload queue and concurrency (max 5 uploads, max 2 image operations) and orchestrates the pipeline.
- @wordpress/vips — wraps wasm-vips in a Web Worker for non-blocking processing; the WASM bundle (including AVIF decoding) loads lazily on first use.
- @wordpress/media-utils — handles HTTP transport to the REST API.
- @wordpress/video-conversion — wraps mediabunny in a Web Worker to convert GIFs to MP4/WebM off the main thread.
- wp_is_client_side_media_processing_enabled() — the PHP feature gate, filterable via wp_client_side_media_processing_enabled.
What plugin developers need to know
Server-side hooks still fire. This is the most common concern, and the answer is that they do. wp_generate_attachment_metadata fires once with context ‘create’ during the initial upload and again with ‘update’ after the finalize endpoint runs. Watermarking, CDN sync, and custom metadata plugins keep working — write them idempotently so they handle both passes. This mirrors how big-image uploads already defer sub-size generation to a second ‘update’ pass. If finalize fails, the error is logged but the upload still succeeds.
To disable client-side processing entirely:
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );Existing filters are honored client-side: big_image_size_threshold, image_editor_output_format, image_save_progressive, wp_image_maybe_exif_rotate, and wp_editor_set_quality (plus jpeg_quality). The supported MIME set is fixed at image/jpeg, image/png, image/gif, image/webp, image/avif — there is no filter to extend it.
Cross-origin isolation. To use SharedArrayBuffer, WordPress sends Document-Isolation-Policy: isolate-and-credentialless on block editor screens for Chromium 137+. External cross-origin scripts automatically get crossorigin=”anonymous”; external images are imported server-side (a new url parameter on the media endpoint) rather than fetched in the browser, since a cross-origin fetch fails in a credentialless document. If your plugin sets a Content Security Policy, include blob: in worker-src or the WASM worker cannot start.
Hooks that no longer fire. Because no server-side editor runs on the client path, wp_image_editors, image_memory_limit, and image_make_intermediate_size do not fire for client-processed uploads.
Browser support and fallback
The full WASM pipeline is currently Chromium-only, because it depends on Document-Isolation-Policy to expose SharedArrayBuffer:
- Chrome / Edge 137+ — full support. Chrome on Android from version 146.
- Firefox / Safari — not supported; falls back to server-side processing with no user-facing change. In-browser HEIC decode still works in Safari on macOS.
Beyond browser support, the client checks device memory (> 2 GB), CPU cores (≥ 2), network class (not 2g/slow-2g, no Save-Data), and that a blob-URL worker can be created. Failing any check falls back transparently. A companion plugin can enable the feature in Firefox/Safari using COEP/COOP headers, which core avoids by default because they break some embeds and third-party resources.
Related REST API tickets
- #64798 — REST API: add dimension validation to the sideload endpoint.
- #65262 — REST API: expose size-aware encode quality on attachment responses.
- #65481 — REST API: support registering one sideloaded file under multiple image sizes.
Media Library inside WordPress 7.1 for developers
Infinite scrolling is now enabled by default in the Media Library grid, with a per-user option to restore the previous pagination behaviour. The release also fixes upload counts, duplicate caption IDs, and other media-management details.
- #65053 — Correct the media-upload count when uploading multiple files from the post editor.
- #65315 — Prevent duplicate figcaption IDs when the same image has different captions.
2. Accessibility
WordPress 7.1 includes accessibility improvements across administration screens, list tables, setup flows, widgets, navigation, and editor-related interfaces. The changes improve semantics, keyboard and pointer interaction, focus behaviour, contrast, and the presentation of contextual information. Accessibility is the single most-represented focus in the release, with 46 tickets.
Administration
Administration improvements make hierarchical relationships and table structure clearer to assistive technologies, and refine focus behaviour, controls, contrast, and interaction patterns across several screens. A notable change is that post list table row headers have changed — worth reviewing if your plugin adds or restyles list-table columns.
Accessible tooltips in core
WordPress 7.1 introduces a shared mechanism for accessible name and informational tooltips. Core now uses it in selected interfaces, giving developers a consistent pattern for presenting supplementary information without relying on inaccessible title attributes or pointer-only interactions.
- #51006 — Add a mechanism for accessible tooltips in core.
- #55343 — Add a tooltip to “Remember Me” on the login form.
- #50921 — Add tooltips for meta box order buttons.
Other accessibility improvements
- #64932 — Make subpage hierarchy in post list tables accessible.
- #65027 — Add IDs to section titles generated by the Settings API.
- #65250 — Correct mouse interaction for the first submenu item when “Collapse Menu” is enabled.
- #65382 — Improve admin colour-scheme contrast for the editor chrome.
- #65454 — Improve accessibility of setup-config.php and install.php.
- #47670 — Fix the accessibility problem caused by multiple RSS widgets.
Additional visibility, contrast, and layout work landed in #65419, #65530, #65532, #65630, and more.
3. Abilities API
WordPress 7.1 builds on the Abilities API introduced in WordPress 6.9, making abilities easier to discover, expose, validate, and integrate with external clients. The release adds filtering to wp_get_abilities(), execution lifecycle hooks, a unified public exposure flag, client-compatible JSON Schema preparation, and several smaller API refinements.
What changed
- Filtering registered abilities. wp_get_abilities() now accepts filtering arguments so callers can retrieve a targeted subset instead of the full registry.
- Execution lifecycle filters. New lifecycle filters let extenders hook into an ability’s execution — before, around, and after the callback runs.
- Unified public exposure flag. A single public flag now governs whether an ability is exposed to external clients, replacing the previous scattered flags.
- Client-compatible JSON Schema. JSON Schema preparation converts an ability’s schema into a form external clients (including AI clients) can consume reliably.
For the full set of smaller refinements, see Abilities API improvements in WordPress 7.1. Related bug fix: #65504 updates the AI Client’s execute_abilities() to check is_ability_call() before executing, mirroring has_ability_calls(), with regression coverage for mixed ability and non-ability calls.
4. Global Styles
WordPress 7.1 expands the styling tools available to block and theme developers, with responsive style variations, configurable viewports, additional interaction (pseudo) states, and text-shadow support — all configured within the Global Styles system.
Responsive block styles
Responsive style states let styles be defined for Tablet and Mobile viewports — both through Global Styles per block type and on individual block instances. They apply to any block type (and its style variations) that uses core block supports such as typography, color, background, border, dimensions, spacing, and layout. The default style is the base and applies at every viewport; Tablet and Mobile override it within their breakpoint ranges.
In theme.json, nest overrides under @mobile / @tablet keys:
"styles": {
"blocks": {
"core/group": {
"spacing": { "padding": { "top": "3rem", "right": "3rem", "bottom": "3rem", "left": "3rem" } },
"@mobile": {
"spacing": { "padding": { "top": "1rem", "right": "1rem", "bottom": "1rem", "left": "1rem" } }
}
}
}
}Responsive and pseudo-states nest viewport-first, then pseudo-state:
"core/button": {
"@mobile": {
":hover": {
"color": { "background": "var:preset|color|contrast", "text": "var:preset|color|base" }
}
}
}Per-instance responsive styles live in the block’s existing style attribute using the same keys, e.g. {“style”:{“@mobile”:{“typography”:{“fontSize”:”1rem”}}}}. On the front end WordPress generates media-query-scoped CSS and adds a stable generated class; non-layout per-instance declarations are marked !important so they override the block’s default inline styles.
Configurable breakpoints
Two breakpoints ship by default:
- @mobile — @media (width <= 480px)
- @tablet — @media (480px < width <= 782px)
There is no @desktop key — the block’s base style is the desktop style. Themes can override the widths with the new top-level settings.viewport values (using px, em, or rem):
"settings": {
"viewport": { "mobile": "30rem", "tablet": "45rem" }
}Values must be non-negative numeric lengths; CSS functions, percentages, unitless values, and other units are ignored. If only one is valid it uses a single max-width query; if the Tablet value is ≤ the Mobile value, only Mobile is used. settings.viewport is global and cannot be set per block type.
Opting out of responsive editing
Set the responsiveEditingEnabled editor setting (default true) to false to remove the viewport entry points from the UI while leaving already-saved responsive styles and their generated CSS untouched:
function example_disable_responsive_editing( $settings ) {
$settings['responsiveEditingEnabled'] = false;
return $settings;
}
add_filter( 'block_editor_settings_all', 'example_disable_responsive_editing' );Pseudo states and text shadow
WordPress 7.1 also adds pseudo and custom style states (such as additional interaction states) and text-shadow support in Global Styles, giving themes and blocks more expressive styling without leaving the Global Styles system.
5. SVG Icon API related to WordPress 7.1 for developers
WordPress 7.0 added a built-in set of SVG icons for the block editor and the core/icon block. In 7.1 this becomes a proper, public API: you can register your own icons, group them into collections, render them on the server, and read them over REST.
Icon collections
Every icon belongs to a named collection, and the collection name becomes a namespace prefix — that is what distinguishes core/plus from my-plugin/plus. WordPress registers one default collection, core. Register your own on init:
wp_register_icon_collection(
'my-plugin',
array(
'label' => __( 'My Plugin Icons', 'my-plugin' ),
'description' => __( 'Icons provided by My Plugin.', 'my-plugin' ),
)
);Collection and icon names must start and end with a lowercase letter or digit and may contain lowercase letters, digits, hyphens, and underscores between. wp_unregister_icon_collection() removes a collection and every icon in it.
Registering icons
Register an icon with wp_register_icon(), supplying a label and either inline content or an absolute file_path (not both). It returns true/false and emits a _doing_it_wrong() notice explaining any failure.
wp_register_icon(
'my-plugin/star',
array(
'label' => __( 'Star', 'my-plugin' ),
'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M12 2l2.9 6.9 7.1.6-5.4 4.7 1.6 7L12 18l-6.2 3.2 1.6-7L2 9.5l7.1-.6z" /></svg>',
)
);Sanitization matters. The SVG is run through wp_kses against a conservative allowlist: only <svg>, <path>, and <polygon> survive, each limited to a fixed set of attributes. fill is kept on the shapes but not the outer <svg>, and stroke is not permitted anywhere — so stick to fill-based shapes for now. file_path is read lazily, so a bad path succeeds at registration and surfaces later as empty content.
Rendering and the Icon block
Render any registered icon in PHP with wp_get_icon( $name, $args ). Arguments: size (px, default 24, or null to keep the SVG’s own size), class (extra classes on the <svg>), and label (an accessible label — omit it and the icon is treated as decorative and hidden from screen readers).
echo wp_get_icon( 'core/plus' );
echo wp_get_icon(
'my-plugin/star',
array( 'size' => 32, 'label' => __( 'Featured', 'my-plugin' ), 'class' => 'my-plugin-star' )
);To make a standalone icon follow the surrounding text color, either add your own fill: currentColor CSS to the class you pass, or put fill=”currentColor” on the shape at registration (it survives sanitization). Inside the Icon block, coloring already works because the block stylesheet sets fill: currentColor on .wp-block-icon svg. The Icon block’s picker now groups icons by collection with per-collection tabs and an “All” tab, and gained flip/rotate controls, a default core/info icon, and server rendering via wp_get_icon().
REST API
All endpoints are read-only GET routes under wp/v2, requiring an authenticated user who can edit_posts: /icon-collections, /icon-collections/<collection>, /icons, /icons/<collection> (new in 7.1), and /icons/<collection>/<name>. The icon list accepts search and (new in 7.1) collection query parameters. Each icon returns its name, label, sanitized content, and collection.
6. DataViews, DataForm, and View Config APIs
The DataViews and DataForm APIs continue to mature in WordPress 7.1, alongside new View Config capabilities for controlling Site Editor screens. Developers can customize data-driven interfaces and filter which views and layouts are available in supported editor contexts — for example limiting or reordering the layouts offered on a given Site Editor screen.
7. Editor
WordPress 7.1 includes a broad collection of editor improvements spanning block behaviour, extensibility APIs, interface components, styling tools, and the editing environment itself. The sections below highlight the changes most likely to affect block, theme, and plugin developers.
New block support
Two new block supports let blocks opt into design controls through their metadata: background gradient (background.gradient) and minimum width. The Custom HTML block also improves: supported blocks can now remain editable inside its preview.
Enforced iframed editor inside WordPress 7.1 for developers
This is the most likely breaking change for block and plugin developers. Starting in WordPress 7.1, the post editor is always iframed — regardless of theme type, the block API versions of registered blocks, or the block API versions of blocks in the content.
Previously the post editor’s iframing was conditional. In 7.0 the decision was based on the block API versions of the blocks actually inserted: if every inserted block was API version 3 or higher it was iframed, otherwise the iframe was dropped for compatibility. The site editor, template editor, and device previews have been iframed unconditionally for some time, so much of this ground is well tested — but the post editor could previously switch modes depending on a post’s content, and that flexibility is now gone.
What to check. Most blocks already work in the iframe. The issues that do come up almost always trace to the same root cause: the iframe has its own document and window, separate from the admin page where editor scripts run. Code that reaches for the global document/window to touch the editor canvas will be looking at the wrong document. The usual fixes:
- Get the canvas document from an element inside it via ownerDocument and its defaultView, rather than the global document/window.
- Use useRefEffect to attach and clean up event listeners on canvas elements.
Also note a related rendering change reported during testing: block CSS is now output more conditionally (for example, Cover block CSS is only emitted when a Cover block is present), which can affect sites that pull rendered content in remotely. See the dev note and Technical considerations for the iframe editor for the full checklist.
Editor components
The editor component library receives new features, refinements, and API updates. Review the editor components updates and the miscellaneous editor changes notes for new capabilities, updated behaviour, and any migration considerations if you build editor interfaces.
8. Design System integrated in WordPress 7.1 for developers
WordPress 7.1 for developers introduces a theming foundation for the WordPress Design System. The approach uses design tokens and shared styles to make interfaces more consistent while giving supported environments a structured way to apply different visual themes. This landed from an earlier merge proposal; the broader proposal continues to evolve.
9. Persistent Admin Bar
The WordPress 7.1 for developers toolbar now remains available while navigating supported editor screens, creating a more consistent path between the front end, the administration area, the Site Editor, and the Block Editor. Developers who extend the toolbar should review how their items behave across these contexts and during client-side navigation, because the bar now persists instead of being torn down and rebuilt on each screen.
10. External libraries
WordPress 7.1 updates bundled third-party dependencies for compatibility, maintenance, and security. The most notable is jQuery UI 1.14.2. If your plugin depends on jQuery UI behaviour or styling, test against the new version.
11. Other updates
Several developer-facing changes do not fall under a larger feature area but may still affect existing integrations. Notably, the notify_post_author filter now has the final say on post-author notifications, so its return value is authoritative even in cases where core previously overrode it.
12. But wait, there’s more! in WordPress 7.1 for developers
WordPress 7.1 for developers offers much more. WordPress 7.1 fixed more than 180 Core bugs, over 630 Gutenberg bugs, 100 enhancements and feature requests, and more than 20 blessed tasks. The following smaller changes may affect integrations, expected return values, generated markup, compatibility, or established workflows.
AI
- #65504 — AI Client: execute_abilities() now mirrors has_ability_calls() by checking is_ability_call() before executing, with regression coverage for mixed calls.
Comments
- #65392 — “Show more comments” failed for comment types other than comment.
Editor and blocks
- #64838 — Prevent block pseudo-state styles from being applied to the default state.
- #65039 — Add context to _doing_it_wrong() messages in WP_Block_Type_Registry::register().
- #65373 — Query Loop block: add an option to exclude the current post.
Formatting and compatibility
- #42517 — Make get_file_data() recognise headers prefixed by a <? tag.
Login, installation, and multisite
- #65506 — Fix incorrect HTTP URLs in multisite signup and activation when SSL is enabled.
Privacy
- #44498 — Run _wp_personal_data_cleanup_requests() on cron.
- #44723 — Return the WP_User_Request user ID as the documented type.
REST API and XML
- #65536 — XML-RPC: fix the argument mismatch in _multisite_getUsersBlogs.
- #65670 — Prevent WP_REST_Attachments_Controller::get_attachment_filesize() from failing on non-integer metadata.
Themes and templates
- #42513 — Improve WP_Theme::get_post_templates() performance for large themes.
- #64848 — Prevent implicit coercion in WP_Theme_JSON::to_ruleset().
- #65049 — Templates: add a date field.
13. What changes didn’t make the WordPress 7.1 for developers release
Contributors did not include every feature explored during the release cycle. They deferred some, changed direction on others, and kept others experimental, giving themselves more time to validate the design and implementation before adding them to Core. Sometimes, what contributors choose not to add is more valuable than what they add.
Classic block still in WordPress 7.1 for developers
An initial proposal would have hidden the Classic block from the inserter for new content while preserving existing instances. After further discussion and testing the change was reverted, so the Classic block remains available in 7.1. Separately, the React 19 upgrade was deferred beyond 7.1 and continues as an experiment in the Gutenberg plugin.
Real-time collaboration
The team extensively tested real-time collaborative editing and gathered feedback throughout the 7.1 cycle, but did not enable it in the final release. Work continues on the editing experience, conflict handling, compatibility, and the path toward a future Core integration. See the collaborative editing outreach effort.
“On This Day” widget
The team considered the proposed “On This Day” dashboard widget but decided not to include it. Further work and discussion can continue in #65801.
Merge proposals
Several projects presented merge proposals during the cycle. Some foundations landed in the release, while broader proposals continue to evolve and may be reconsidered after further testing, documentation, and feedback — including Guidelines built on Knowledge and Design System Theming.
Source: WordPress 7.1 Field Guide, Make WordPress Core (published August 5, 2026). This document expands each section with detail drawn from the individual developer notes linked throughout.