WordPress 7.1 Beta 1: What Shipped and What to Test

Beta 1 is the day the feature list stops being a wish and starts being a contract. Everything not in this build has to justify itself as an exception, everything in it is what agencies like ours will support in production a month from now. So when a 7.x cycle hits Beta 1, I clear an hour, pull it onto a staging box, and read the announcement with a keyboard in front of me, not a browser tab.

WordPress 7.1 Beta 1 shipped yesterday. It is the biggest visible cycle in a while — Notes finally grew up, responsive styling landed for real, the toolbar stopped being a mystery, and the media pipeline moved another step toward the browser. It is also the first cycle in a good while where the block editor changes are less about “here is the primitive” and more about “here is the finished product experience”.

Here is what actually shipped, what to test this week, and what I would not touch until RC 1.

What is actually new

WordPress 7.1 Beta 1 was published July 15, 2026 by Krupa Nanda on wordpress.org/news, with a general release scheduled for August 19, 2026 to align with WordCamp US per the release party schedule. Anne McCarthy is the release lead. Four testing paths are documented: the WordPress Beta Tester plugin on the Bleeding edge / Beta/RC Only channel, the direct zip, wp core update --version=7.1-beta1, or WordPress Playground in the browser. Do not run it on production. That warning is in the announcement for a reason.

The feature set clusters into five areas.

Notes grew up. Inline formatting (bold, italic, code, links, emoji), @mentions to tag collaborators, multiple conversations per block, comments on selected text, and collapsible long threads. This is the first cycle where Notes stops feeling like a proof of concept and starts feeling like something an editorial team can actually run a review flow on. It is also the piece most directly affected by the fact that Real Time Collaboration was pulled from 7.0 in May and remains, in the language of the 7.1 roadmap, with “strategic decisions pending” — asynchronous collaboration via Notes is what the project can ship confidently while RTC gets sorted separately.

Responsive styling is here. You can now define per-viewport values (font size, spacing, block visibility) directly in the editor without writing custom CSS. Theme authors can customise breakpoints. Interactive-state styling (hover, focus, active) rides on the same style-states mechanism. This is the payoff for the Gutenberg 23.5 work that merged the resizable canvas with the device dropdown so canvas width in pixels is the single source of truth for what viewport you are editing.

Media processing moved into the browser. Client-side pipelines now handle HEIC, UltraHDR, AVIF, WebP, plus GIF-to-video conversion. A dedicated media editor modal replaces the old inline crop UI. Attached-images auto-population and infinite scrolling round out the library. For teams shipping photo-heavy sites this is the difference between “iPhone drops a 40 MB HEIC into the library and the server hates you” and “browser converts, sends WebP, moves on”.

Admin navigation got consistent. The persistent toolbar dev note by Ashar Fuadi (July 13, 2026) confirms the admin bar now shows in the Post and Site Editors by default, the ambiguous “W” logo becomes a proper back chevron, and configured site icons appear in the toolbar. Distraction Free mode still hides the toolbar. Plugin developers should test any custom admin_bar_menu node — the Site Editor is now a first-class toolbar surface. There is a Site Editor admin color scheme, an improved command palette with grouped results, post excerpts in list view, a visual revision picker, an “On This Day” widget, editable comment threading, and a persistent omnibar across editors.

New blocks and developer APIs. Two new core blocks land: a Playlist block with waveform visualisation for audio collections, and a Tabs block for tabbed content. Table of Contents was on the roadmap; the Beta 1 announcement lists Playlist and Tabs explicitly. On the developer side: Abilities API expansion (context in the core abilities merge proposal), Block Bindings for list items, custom icon registration, enforced iframed editor for block themes (predictable rendering), and enhanced Connector authentication. React 19 is back behind an experimental flag with a compatibility layer. Speculative loading default moves from conservative to moderate when caching is detected.

Named contributors on the announcement: @benjamin_zekavica, @amykamala, @wildworks, @adamsilverstein, @annezazu, @fushar, @jorgefilipecosta, @joedolson. The release party ran at 15:00 UTC on July 15 in #core Slack with @krupajnanda as emcee, per the schedule.

Why it matters for WordPress and WooCommerce people

Beta 1 pins trunk to the wp/7.1 branch. From here on, only bug fixes and dev-feedback commits get in. The names lock now. That means the API surface your plugin or theme has to be compatible with on August 19 is exactly what is in Beta 1 today. If a filter name changes between Beta 1 and RC 1, it will change because of a hard blocker, not because someone had a better idea.

Three compatibility items agencies should audit this week:

Custom admin bar nodes in the editor. The Site Editor is a new toolbar host. Any plugin that registers admin_bar_menu nodes needs to be tested inside the Site Editor and the Post Editor. If you have nodes that assume they are on a classic admin screen (relying on specific DOM around them, or on the fact that the toolbar was previously hidden in the block editor), they will now render in a place they were never designed for. Either scope them out with $screen->is_block_editor() or make them work.

Iframed editor for block themes. This is now enforced. Classic-editor-era assumptions about the DOM being in the top-level document break here. Any theme or plugin that enqueues stylesheets or scripts assuming direct DOM access from window without going through the iframe context needs to be re-tested against a block theme in the Site Editor. The signals were there in earlier cycles — 7.1 makes it non-optional.

WooCommerce 11.0 lands July 28. That is nine days after Beta 1, twelve days before WordPress 7.1 RC 1 on August 5, twenty-two days before 7.1 general release. If you followed the WooCommerce 11.0 developer preview, you know 11.0 brings product object caching default-on for new stores, block-based product editor beta removal, the get_queried_object() shape change on the Shop page, and product shipping class becoming private. Do not test WooCommerce 11.0 on top of WordPress 7.1 Beta 1 as your primary staging pass. That is two moving targets stacked. Test WooCommerce 11.0 on WordPress 7.0.1 stable first, then test WordPress 7.1 on top separately once RC 1 is out.

What I would do (or not do) about it

Install WordPress 7.1 Beta 1 on a fresh staging box this week. Not on top of your production database — a clean install, or a clone of a real client site that you can throw away. Turn on a block theme (Twenty Twenty-Six or Twenty Twenty-Five). Then run four passes:

Editor pass. Open a long-form post. Add Notes with @mentions and inline formatting. Verify multi-conversation threads on a single block. Set per-viewport font sizes on a heading. Try the new Playlist and Tabs blocks. Watch the toolbar behaviour — does it stay visible, does the back chevron do what you expect, does your admin color scheme carry into the Site Editor?

Media pass. Drop a HEIC file straight from an iPhone into the media library. Confirm it converts client-side, not server-side. Try a large AVIF. Open the new media editor modal. Note anything that takes more than a couple of seconds — client-side processing has a floor, and you want to know where it is before a client hits it.

Compatibility pass. Install your five most-used custom plugins and your active theme. Grep for admin_bar_menu, direct document.querySelector calls from editor scripts, and any code that assumes the Classic block will not be in the inserter (spoiler: it will — the July 7 reversal we covered on July 12 holds in Beta 1). File issues against your own plugins now, before Beta 2 on July 22 pushes another sync.

Performance pass. Speculative loading default is moving from conservative to moderate when caching is detected. If you run a persistent object cache (Redis, Memcached) or a full-page cache (Varnish, LiteSpeed, hosted equivalents), the site now speculatively prefetches more aggressively. Watch server logs on a realistic browsing session. Most sites will benefit. A few — the ones with expensive dynamic endpoints that were never meant to be prefetched — will need wp_speculation_rules_configuration filter attention.

What I would not do: run 7.1 Beta 1 on any production site, on any staging site that mirrors production data that clients might see, or on a store currently doing black-box acceptance testing for WooCommerce 11.0. Wait for RC 1 on August 5 to start real integration work. Wait for 7.1 general release on August 19 to update production, and then only after WooCommerce has confirmed 11.x compatibility.

Two cycles ago I would have said “and file everything you find on Trac”. The advice still holds. But this cycle the Notes and toolbar and media changes are visible enough that a good chunk of what you find will be usability signal, not bugs — write those up too. The 7.1 release squad has been unusually responsive to well-formed feedback (see the Classic block reversal), and Beta 1 to Beta 3 is the window where feedback still moves.

Beta 1 is a small hour of work now to buy a much calmer August. Do the hour.