WordPress.org

WordPress Developer Blog

What’s new for developers (July 2026)

What’s new for developers (July 2026)

July is the month the WordPress 7.1 cycle gets real. Beta 1 lands on July 15, betas follow weekly through the end of the month, and the final release is scheduled for August 19, 2026, timed with WordCamp US. If June was about wrapping up WordPress 7.0, July is about deciding what you need to test before 7.1 locks in.

Meanwhile, WordPress 7.0.1 was released on July 9. It bundles 13 Core tickets and 13 Gutenberg fixes, all bug-fix only.

On the plugin side, Gutenberg 23.4 (June 17) and 23.5 (July 1) both shipped in the window. Note that Gutenberg 23.5 raises the plugin’s minimum required WordPress version to 6.9.As usual, when testing features mentioned in these What’s new? posts, ensure that you’re running the latest version of WordPress and the latest version of the Gutenberg plugin. You can also test the latest updates via Playground.

Highlights

WordPress 7.1: mark your calendars

The 7.1 cycle now has a release squad, a release party schedule, and a bug scrub schedule

The key dates:

  • Beta 1 on July 15
  • Beta 2 on July 22
  • Beta 3 on July 29
  • Release Candidate 1 on August 5
  • Final release on August 19, 2026, during WordCamp US.

The Roadmap to 7.1 is the post to read closely. Beyond the items detailed below, it lists pseudo-state styling, new Playlist, Table of Contents, and Tabs blocks, an enforced iframed editor for block themes, and a change that moves the speculative loading default from conservative to moderate when caching is detected.Beta 1 arrives just days after this post is published. If you maintain plugins or themes, the next few weeks are the window to influence what ships and to catch compatibility issues while they are still cheap to fix.

Responsive styling is ready for testing

Responsive style states have appeared in these roundups for months as work in progress. That changed on July 3 with an official Call for Testing: Responsive Styling. You can now style blocks per viewport directly in the editor, and Gutenberg 23.5 replaces the fixed desktop/tablet/mobile preview toggle with a unified, freely resizable device preview.

There are real developer implications here. The useResizeCanvas() hook is deprecated and no longer operational, while getDeviceType() and setDeviceType() continue to work. Blocks that use standard block supports get responsive styles for free; blocks with custom controls do not. On the Core side, the @ prefix syntax for responsive style states has been adopted, and aspect-ratio and flex-alignment controls now work inside viewport states. If your blocks ship custom style controls, or your themes lean on theme.json presets, run through the call for testing and report what breaks.

Merge proposal: expanding Core Abilities

The Abilities API shipped as infrastructure in WordPress 6.9, and a new merge proposal aims to add the first practical abilities to Core: core/read-settings, core/read-content, and core/read-users. All three are read-only and built on existing capability checks, with core/manage-* abilities planned for future releases.

Hardening work continued alongside the proposal: ability filtering was refined and meta is now exposed over REST, JSON Schema helpers were consolidated for reuse, and the JavaScript packages gained URI schema format support.

If you are building AI or automation features against the Abilities API, this proposal defines the first Core-provided abilities your code will be able to rely on. Feedback is open now.

Merge proposal: Guidelines built on Knowledge

The Guidelines experiment covered in earlier roundups has grown into a broader merge proposal for WordPress. It introduces a wp_knowledge custom post type — a single place to store site knowledge, with permissions and revisions built in. It ships with three knowledge types (guideline, memory, and note), and a filter lets you register your own.

The proposal includes REST routes at /wp/v2/knowledge and dedicated *_knowledge_item capabilities, and it is designed to have zero footprint on sites that never use it. To make 7.1, it needs to land by Beta 1 on July 15, so check the proposal’s status when you read this.

Plugins & Tools

React 19: test your plugins now

June’s roundup covered the temporary revert of the React 19 upgrade. The action item has now changed from “watch” to “test.” Gutenberg 23.4 ships an experimental gutenberg-react-19 flag that swaps the React 18 bundles for React 19 at runtime, simulating exactly what published plugins will face when WordPress makes the jump. Compatibility polyfills log console warnings whenever a plugin hits a removed legacy internal.

If your plugin ships compiled JSX, uses @wordpress/element, or touches editor internals, enable the flag under Gutenberg’s Experiments screen and watch the console. Every warning you fix now is a support ticket you avoid in August.

Components drop the 40px opt-in prop

The biggest extender-facing change in the window is a coordinated hard-deprecation wave across @wordpress/components. Starting with TextControl on June 23 and continuing through roughly 20 components — including BoxControl, BorderControl, FontSizePicker, RangeControl, ComboboxControl, ToggleGroupControl, UnitControl, FormTokenField, and CustomSelectControl — the __next40pxDefaultSize prop is hard-deprecated for WordPress 7.1.

The 40px control size becomes the permanent default, and the prop becomes a no-op. If your plugin UI passes __next40pxDefaultSize today, it will keep working, but expect deprecation warnings; if your UI relied on the old smaller default without the prop, review your layouts against the new sizing.

Icons now inherit color, and the Icons API takes shape

All 330 icons in @wordpress/icons v15 now declare fill="currentColor", a breaking change for anyone styling icons with CSS. Tint icons with the CSS color property instead of fill going forward.

This lands amid steady buildout of the Icons API headed for WordPress 7.1: a new wp/v2/icon-collections REST endpoint, label-based search in WP_Icons_Registry, and stricter slug validation. The roadmap confirms register_icon() and unregister_icon() are planned for 7.1.

Unicode email addresses: call for testing

June’s roundup flagged the Unicode email proposal as open for feedback. It has since merged into trunk, closing a ticket opened in 2015, and there is now an official call for testing.

WordPress now accepts UTF-8 local parts on sites with `utf8mb4` database support, handles internationalized domains via Punycode, and introduces a new WP_Email_Address class. If your plugin validates, stores, or compares email addresses — especially through is_email() or sanitize_email() — test against Unicode addresses now. The behavior can be disabled with a filter if needed.

Classic block status in WordPress 7.1

Originally, there was a plan to hide the Classic block from the inserter for 7.1. This decision has been reverted and the Classic block will remain in WordPress for the foreseeable future and instead focus on creating experiences that users will choose instead of being forced to use.

AI Client: streaming and embeddings coming in 7.1

The AI team published a look at what’s coming to the AI Client in WordPress 7.1: streaming for generation responses and embeddings support for semantic and vector search. The focus remains on primitives for plugin developers rather than user-facing AI features.

Package-level changes worth a changelog read

Several changes affect anyone consuming @wordpress/* packages directly:

– The @wordpress/reusable-blocks package is deprecated. All core/reusable-blocks store actions and selectors, plus ReusableBlocksMenuItems, now log deprecation warnings, and the package is on a path to becoming a no-op. This has been milestoned for  Gutenberg 23.6 whose release date has been moved to July 22nd.

– A dependency-surface cleanup fixed published dependencies across roughly 30 packages, made @types/react an optional peer dependency, and fixed a rememo type leak.

One warning for block developers: the experimental Tabs block removed its public core/tabs store as part of pre-stabilization cleanup. Do not build against it — the block is on the 7.1 roadmap, and its internals are still shifting.

WordPress Studio now available on Linux

WordPress Studio saw some big releases the the last month. Version 1.10 added Linux support and 1.11.0 added Studio Code, WordPress.com’s agentic development tool, to the desktop app. It requires a WordPress.com to use, but usage is free during the beta phase.

Media: pipeline follow-ups and the return of infinite scrolling

The client-side media processing work covered in June kept moving on the server side: GIF uploads can now generate video companion files, HEIC and HEIF uploads are accepted even without server-side editor support, and the REST attachment endpoint gained output format, progressive rendering, and quality fields. Gutenberg 23.4 added offline-resilient upload queues and preserves Ultra HDR gain maps when transcoding.

Separately, the Media Library is getting infinite scrolling back, reversing a removal that dates to WordPress 5.8 — this time with a user opt-out option.

Plugin Directory screenshot galleries rebuilt

The Plugin Directory rebuilt its screenshot galleries using the core Gallery and Image blocks with lightbox support, an adaptive layout, and no more cropped previews. If you maintain a plugin listing, take a minute to check how your screenshots render now.

Performance: what to watch for 7.1

The performance team’s 7.1 priorities, per recent performance chat summaries, are frontend View Transitions and Enhanced Responsive Images as feature plugins, plus groundwork for a libvips-based image editor in Core. And per the roadmap, the speculative loading default moves from conservative to moderate when a caching solution is detected.

Themes

The admin bar returns to the post and site editors

Graduating from the omnibar experiment, the admin bar now shows by default in both the post and site editors, and the W-logo corner has been replaced with a back button. This is headed to WordPress 7.1.

If your plugin injects UI near the editor header, retest your layout. Related cleanup moved the Gutenberg Experiments screen under Settings and removed the top-level Gutenberg admin menu.

Layout: real fixed widths and auto-fit grids

Two layout changes give theme authors more precise control. Flex children with a “fixed” width are now truly fixed via flex-shrink: 0, with the old squishable behavior renamed “Max width.” And grid layouts gained a “fill available space” toggle (releasing July 22nd with Gutenberg 23.6) that switches column behavior from auto-fill to auto-fit through a new autoFit layout property. Both changes have landed in Core for 7.1, alongside flex vertical alignment controls in the inspector. 

Block Bindings expand to List Items and nested content

Block Bindings gained List Item block support in Core, and bound rich text now preserves nested inner blocks instead of flattening them. The 7.1 roadmap lists bindings for list items and inner blocks as a headline item, so expect more here before Beta 1.

New extensibility surfaces for block variations

Two quieter changes open up new patterns. Custom HTML block variations can now ship innerContent, so registerBlockVariation( 'core/html', { innerContent: [ /* ... */ ] } ) lets you distribute static markup with editable slots. And block transforms can now target specific variations, enabling transforms like Columns or Gallery straight into a Grid variation.

More theme-facing block updates

Smaller changes worth noting: Global Styles gained textShadow support in Gutenberg 23.5; block visibility metadata is now honored in excerpts, and blocks with visibility: false are hidden everywhere; the Verse block supports background gradients; the Icon block gained flip and rotate controls plus block.json default icon support; a wp-elements-* class collision was fixed; and calc() expressions now accept unitless zeros.

Also worth keeping an eye on: an experimental Dynamic Gallery block variation landed in Gutenberg that automatically renders media attached to the post, a first step toward folder- and tag-driven galleries. This is experimental — test it in Gutenberg, but do not build on it yet.

Playground

The Playground team shipped releases v3.1.39 through v3.1.43 during the window. A changelog automation bug left those release notes empty (since fixed), so here is what actually landed.

Blueprint steps you can use today

Blueprint authors picked up several practical upgrades. The installPlugin step gained activationOptions, making setup data available during the activation hook, plus onError: "skip-plugin" for optional installs that should not fail the whole Blueprint (themes got the same treatment). WXR imports gained controls to preserve source URLs, skip attachments, skip comments, and set a default author. And rewrite rules are now flushed automatically after setting permalinks via setSiteOptions.

MCP meets the Abilities API

Personal Playground gained MCP support along with a playground_ability meta-tool: instead of exposing one MCP tool per registered ability, agents can list, inspect, and execute abilities through a single tool. It is a nice illustration of the Abilities API working as designed — the same abilities proposed for Core merge above become directly callable by AI agents in Playground.

Personal Playground: remote access over WebRTC

You can now open your Personal Playground from another device over WebRTC. The relay server only handles signaling; the actual traffic flows browser to browser.

Blueprint v2 is coming together

Roughly 30 merged PRs built out the Blueprint v2 compiler, including a compileBlueprintForExecution() facade and PHP/WordPress version-constraint resolution. This is infrastructure in progress, not an announced feature — the v2 syntax is not ready to use yet, but the pace suggests it is worth following.

CLI users also got fixes for a SQLite crash on shutdown and mount preservation for long-running sessions, and Playground’s SQLite journal mode now defaults to DELETE.

User-facing changes

A few smaller updates land closer to the user side but are worth knowing about: the Site Editor now respects admin color schemes, real-time collaboration can be disabled per post type, and new-user notification emails no longer include the username. On the security side, oEmbed provider URLs are now validated before use.

Resources

Developer Blog

One new tutorial was published on the Developer Blog in the past month:

Dynamically loading template parts in block themes

General

What’s new in Gutenberg 23.4 (June 17) and What’s new in Gutenberg 23.5 (July 1)

WordPress 7.0 release retrospective — the survey is open until July 20

WordPress 7.0.1 release schedule

Guidelines for syncing code from Gutenberg into wordpress-develop

Recap: restoring removed version history

Core Committers meeting at WordCamp Europe 2026

Props to @bph and @greenshady for reviewing this article.

3 responses to “What’s new for developers (July 2026)”

  1. Juan Pablo Avatar

    Hello WordPress, I’m getting more excited about it every day. I’ve been testing the responsive styles and it’s wonderful, thank you for this, it’s really useful. I have a comment: if I add different styles, for example, for tablets, it would be more like the styles are maintained on mobile, and I wouldn’t have to repeat the settings on mobile. This would make page layout much more practical, and the markup would be much shorter. Do you plan to also make it work for the number of columns per viewport? That would be very useful, especially since it also depends on the markup. I’ve been building websites with Gutenberg for several years, and what I always need most is to be able to freely structure columns and grids according to the viewport and thus control the size of things, because generally the text and image styles always stay the same.

    Thank you very much for everything.

    1. Juan Pablo Avatar

      When I talk about markup, I mean the markup it’s not visible in the comment because it was deleted when it was published.

  2. Anh Tran Avatar

    These new abilities planned for WordPress 7.1 look very promising and should provide a solid foundation for AI-powered workflows in WordPress.

    I’m especially hoping that the MCP adapter will eventually become part of WordPress Core as well. Having it officially supported would make these abilities much more practical and provide a standard, interoperable way for AI clients and tools to interact with WordPress, rather than relying on separate implementations.

Leave a Reply

Your email address will not be published. Required fields are marked *