Wordify
Get started
← Back to blog
· by The Wordify Team · in WordPress News

WordPress 7.1: what's coming for site owners (and what isn't)

WordPress 7.1: responsive styling, modern media formats, and editorial Notes

Before you read: WordPress 7.1 has not shipped yet. This preview is based on Release Candidate 1, the Field Guide, and Make WordPress Core notes, checked August 13, 2026 (RC3 landed August 12). The feature set froze at RC1, but details can still change before the final release. We'll update this post on release day.

WordPress 7.1 is scheduled for August 19, 2026, on the final day of WordCamp US. It is a feature release. That changes how you should treat it compared with a security-only minor like 7.0.3 or 7.0.4: majors want staging, plugin compatibility checks, and a deliberate cutover, not a quiet overnight auto-update.

RC1 froze the feature set. Below is what is set to ship, what got cut, who should care first, and the staging checks we'd run before promoting a client site.

What's new, in practice

7.0 led with AI foundations. 7.1 is quieter, and for most agencies and site operators it is the more useful day-to-day release.

Three themes carry it:

  1. Styling without a stylesheet: responsive controls and interactive states in the editor
  2. Media that matches how people shoot: client-side processing, modern formats, a dedicated crop and rotate modal
  3. Less admin friction: a persistent toolbar, Notes that work for real editorial feedback, and two new Core blocks for jobs that used to need a plugin

What it is not: real-time co-editing. That was on the roadmap, got extensive testing this cycle, and is again not enabled in the final release. Saying what did not ship is as useful as listing what did.

Responsive styling and interactive states

This is the change most likely to shorten a build.

You can define how a block looks at different screen sizes from inside the editor: Global Styles for every instance of a block type, or on a single block. Theme authors can set the Tablet and Mobile breakpoints in theme.json instead of living with Core's defaults. There is also an off switch (responsiveEditingEnabled) if you want to hide the responsive UI without stripping styles already saved.

Interactive states land alongside it: hover, focus, focus-visible, and active as editor controls rather than custom CSS. In 7.1 that support is real but narrow: Button and Navigation Link are the blocks with the standardised controls. Custom "current menu item" styling is available via theme.json only (no user-facing UI yet). Further states continue after this release.

Our read: this closes two of the most common reasons people still reach for a page builder or a CSS snippet for buttons and nav. It does not make every block fully responsive out of the box. Test with your theme; the controls only help where the theme and block supports allow them.

Media: the practical win

Client-side media processing, punted from 7.0, lands here. Supported image work can happen in the browser (via a WebAssembly build of libvips) before the file hits your server. Format support covers what phones actually produce:

  • HEIC (default for iPhone photos)
  • Ultra HDR / HDR gain maps
  • AVIF and WebP
  • Animated GIF to video conversion for opaque GIFs in supporting browsers (reversible in the editor; transparent GIFs stay images)

The full WASM pipeline is Chromium-oriented today. Firefox and Safari fall back to the existing server-side path, so behaviour is not identical across every browser your editors use. Uploads get a progress indicator and automatic retries if the connection drops. The Media Library grid uses infinite scrolling by default, with a per-user opt-out on the profile screen.

A new Media Editor modal replaces the old inline cropper, bringing crop, rotation, and metadata editing into one place. Galleries can pull media already attached to the current post, and the inserter surfaces those attached images so you're not re-uploading duplicates.

If you run image-optimisation plugins, CDNs, or offload media to remote storage, test this on staging. Some server-side hooks may not fire the way they used to when processing moves into the browser. That is a plugin-compat issue worth catching before production, not a reason to skip the release.

Notes: usable async feedback, not Google Docs

Notes grow into something an editorial team can actually use:

  • Notes on a text selection, not only a whole block
  • Multiple note threads on the same block
  • Rich text (bold, italic, links, code)
  • @mentions, with email notifications when you're tagged (landed in the RC window)
  • Long notes collapse behind show more / show less
  • Shareable links to specific revisions

What this is: asynchronous feedback that doesn't require screenshots and "look at the third paragraph" emails.

What this is not: real-time collaboration. No shared cursors, no live co-editing, no disappearing post lock. The Field Guide is explicit: real-time collaborative editing received extensive testing in the 7.1 cycle and is not enabled in the final release. Work continues on conflict handling and the path into Core. If you were waiting for Docs-style co-editing, wait for a later release. Notes are the collaboration investment this cycle.

Admin friction that compounds

A handful of small changes that add up if you live in wp-admin:

Change What you get
Persistent admin bar Toolbar stays available in the Site Editor and Block Editor (hidden in Distraction Free mode)
Command palette Results grouped into Recent, Suggested, and Matching; recent commands persist across sessions
Admin colour scheme in Site Editor Site Editor follows your chosen admin scheme instead of a fixed dark shell
Identity section Logo, favicon, title, and tagline in one Site Editor screen
Excerpts in the posts list Short excerpts make untitled or similar posts easier to tell apart without opening them
Comment parent Edit Comment screen gets an "In reply to" control: no more database surgery for a misthreaded reply

The Classic block was going to be hidden from the inserter. That decision was reverted on July 7, 2026. Nothing changes for Classic block users in 7.1: it stays in the inserter, existing content keeps working, no migration, no companion plugin required.

New blocks: Tabs and Playlist

Two Core blocks that used to mean a third-party dependency:

  • Tabs: tabbed panels for FAQs, feature comparisons, and anything that shouldn't be a wall of text
  • Playlist: audio collections with optional waveform visualisation; podcasts, talks, and music without a separate player plugin

The Table of Contents block was on the June roadmap next to these two. It did not appear in the Beta 1 shipping list and is not part of 7.1. Don't plan a migration around it yet.

Also worth knowing among the smaller block changes: background gradients can layer with background images on Group and several other blocks; Image gets a "Mark as decorative" toggle for accessibility; shortcodes paste into proper Embed blocks more cleanly.

What's not in 7.1

This is the section most release posts skip. It is often the useful one for planning.

Expected / discussed Status in 7.1
Real-time collaboration Not enabled. Continues for a future release.
Table of Contents block On the June roadmap; not in the Beta 1 / shipping block list.
"On This Day" dashboard widget Mentioned in Beta 1 coverage, then not included (Field Guide).
Hiding the Classic block Reverted. Behaviour unchanged.
Guidelines (editorial rules / brand voice for AI) Merge proposal evolved during the cycle; not a finished user-facing feature of 7.1.
React 19 in Core Punted. Experiment continues in the Gutenberg plugin first.
Notes suggestion mode / emoji reactions On the early roadmap; not in the Beta 1 feature set. Treat as not shipping unless the final release post says otherwise.

Cutting these is not a failure of the release. It is Core choosing not to ship half-ready collaboration, and not to force Classic users off a bridge that still carries traffic.

Developer-facing, only where it hits site owners

Most of 7.1's API work is for extenders. Two items matter if you run custom blocks or older plugins:

  1. Enforced iframed post editor. The post editor always runs in an iframe now, regardless of which blocks are in the post. Blocks still on Block API v2 or lower need updating to v3. If you maintain custom blocks, or you rely on plugins that inject admin styles into the canvas, this is the compatibility check to do first. WordPress publishes a migration guide.
  2. jQuery UI 1.14.2. Dependency bumps break things quietly. Anything still leaning on jQuery UI widgets deserves a staging pass.

Hosts also get a practical knob: speculative loading defaults can be tuned via environment variables or wp-config.php constants, so a well-cached stack can opt into more aggressive prefetch/prerender without an mu-plugin.

Who should upgrade, and when

Situation Advice
Simple brochure site, current theme, well-maintained plugins Staging first, then production within a week of release once your critical plugins show "Tested up to: 7.1"
Agency / multi-site fleet Pilot on a non-critical site, then roll out. Don't day-one the whole fleet.
WooCommerce, membership, booking, or heavy custom code Staging mandatory. Run checkout, forms, logins, and media uploads before touching production.
Waiting only for real-time collab or ToC Stay on 7.0.x (patched). Those features are not why you'd move.
Still behind on 7.0.4 Take the security release now: it patches a High-severity remote code execution issue. Don't sit on an unpatched 7.0.x waiting for 7.1.

What to test on staging

Suggested sequence once 7.1 is final:

  1. Confirm you're on 7.0.4 (or the current patched minor for your branch).
  2. Full backup you have actually restored from once.
  3. Clone to staging.
  4. Update plugins and theme on staging first.
  5. Update core to 7.1 on staging.
  6. Exercise the paths that actually change in this release:
    • Editor: open posts with custom blocks; confirm the canvas still looks right under the enforced iframe
    • Media: upload a HEIC if clients send iPhone photos; try crop/rotate; check any image-optimisation or offload plugin
    • Front end: forms, checkout, logins, and any page that depends on Tabs, Playlist, or button/nav hover styles
    • Admin: Notes, @mentions, and the persistent toolbar with your usual editor plugins
  7. Promote to production when that pass is clean.

A major feature release is not a security-only minor. Treat it accordingly.

Common questions

When does WordPress 7.1 release?

August 19, 2026, timed to WordCamp US. Release Candidate 1 landed August 5, 2026 and RC3 on August 12, with a dry run scheduled for August 18.

Is this a security release?

No. It is a major feature release. Security-only updates (like 7.0.4) are a different shape of release and a different urgency.

Does 7.1 include real-time collaboration?

No. Notes improvements are what shipped for collaboration. Real-time editing is not enabled in 7.1.

Will the Classic block disappear?

No. A plan to hide it from the inserter was reverted. Behaviour in 7.1 matches what you have today.

Will this break my site?

Most sites on current, maintained plugins will be fine after a normal staging pass. The highest-risk areas are custom or older blocks still on Block API v2, plus media plugins that assume all image processing happens on the server. Test those two paths deliberately.

Should I update on day one?

Only if the site is simple and you've already tested. For anything with ecommerce, memberships, or custom development, wait for plugin authors to mark 7.1 compatibility, run staging, then cut over. Security minors are urgent; feature majors are careful.

I'm on WordPress 6.x. Do I need 7.1?

Not for security. Stay current on your branch's latest minor for patches. Move to 7.1 when you want the styling, media, and Notes work, after staging, not because a calendar says so.

The unglamorous point

7.1 is a finishing release: responsive and hover controls that should have been editor-native years ago, media handling that accepts the formats phones produce, Notes that make async review less painful, and admin navigation that stops fighting you.

The risk is not the features. It is treating a major like a minor. Auto-updates that sensibly absorb a security-only release are the wrong default for a jump that changes the editor canvas, media pipeline, and a pile of block APIs underneath.

On Wordify, Automated Safe Updates apply plugin, theme and core updates, run a health check afterwards, and roll the site back on their own if something breaks. For a major like 7.1, the right move is still staging first: one-click staging is there for exactly this, then a controlled production update once the pass looks clean. Majors need more care than a 7.0.4-style auto minor. That is the boring half of keeping sites current, and it is the half that usually fails.

If you want a hand checking a fleet before August 19, 2026, talk to us and we'll run through it with you.

More on this

Sources