WordPress 7.1 ships on 19 August 2026, timed to the closing day of WordCamp US in Phoenix. Both release candidates are out, the feature set is locked, and the Field Guide is published. That gives you about a week to test before it lands.
This release is aimed squarely at people who build and style sites rather than people who write plugins. Two things theme authors have been asking for since block themes arrived are finally in core, and a fair amount of custom CSS becomes unnecessary.
First: check you are on 7.0.3
Before anything else. Two security releases landed in the last month:
- 7.0.2 on 17 July, fixing one critical and one high severity issue. The severity was serious enough that WordPress.org enabled forced updates for affected versions.
- 7.0.3 on 6 August, with roughly a dozen further fixes.
Most sites took both automatically. But if a previous developer disabled auto-updates, or a security plugin is blocking them, or the site is on a locked-down managed host, you may have missed them. Check Dashboard → Updates now rather than after reading the rest of this.
Responsive styling without custom CSS
This is the headline for anyone who builds sites. You can now set styles for tablet and mobile viewports directly, both globally per block type and on individual blocks. In theme.json they nest under @mobile and @tablet keys.
There is deliberately no @desktop key. The block’s normal style is the desktop style, and it keeps applying at every viewport for any property you have not overridden. That is the right mental model — you are layering overrides downward, not defining three separate designs.
Themes can also set their own breakpoints via a new top-level settings.viewport property. Defaults are 480px for mobile and 782px for tablet. Values must be non-negative lengths in px, em or rem; percentages, unitless values and CSS functions are ignored. It is a top-level setting, so you cannot vary it per block.
The practical catch: blocks using standard block supports get responsive styles free, which covers typography, colour, background, border, dimensions, spacing and layout. Blocks with custom style controls do not. If you run a third-party block library, that is the line to test against.
Hover and focus states, finally
Alongside responsive styles, you can now define :hover, :focus, :focus-visible and :active states in theme.json and through the editor. For this release it is limited to the Button and Navigation Link blocks.
Between these two features, a meaningful chunk of the custom CSS on a typical block-theme site becomes redundant. That matters beyond convenience: custom CSS is where sites accumulate the fragile, undocumented styling that breaks three years later when nobody remembers writing it.
The change most likely to break something
In post list tables, the primary th scope="row" has moved from the checkbox column to the title column. The checkbox cell is now a td, the title cell is now a th carrying an aria-label, and collapsed cells in responsive view use flex layout.
It is a genuine accessibility win — screen readers now identify each row by the post rather than by a checkbox that might not even be there. But this markup has been broadly stable since 2010, and a lot of plugins depend on it without saying so. Anything with CSS or JavaScript selecting th.check-column, or expecting row actions inside a td, needs checking.
If you maintain custom admin columns for a client, this is the one to test.
The post editor is now always iframed
In 7.0 this was decided per post depending on which blocks were present, meaning the editor could switch modes based on content. That conditional behaviour is gone: the post editor is always iframed now, regardless of theme type, block API version, or legacy meta boxes.
Most blocks are unaffected. The problems that do appear nearly always trace to one cause: the iframe has its own document and window, separate from the admin page where editor scripts run. Any code reaching for the global document or window to touch the canvas is looking at the wrong document.
In practice this bites older custom blocks and blocks still on Block API version 2 or lower. If your site has bespoke blocks from a previous developer, test on staging.
What is not in this release
Worth being clear, because coverage has been muddled:
- Real-time collaboration is not in 7.1. It was cut from 7.0 late in the cycle and has not returned. Notes got the collaboration investment instead, picking up email notifications for mentions and shareable revision links.
- React 19 has been punted again. It was briefly enabled in Gutenberg then reverted after incompatibilities surfaced. Core stays on 18.3.
- The Classic block stays in the inserter. The plan to hide it was reverted.
Also worth knowing
- The SVG Icon API is now public, so plugins can register their own icon collections. Registered SVGs are sanitised to a conservative allowlist — only
svg,pathandpolygon. - A new
background.gradientsupport renders through thebackground-imagelonghand rather than the shorthand, so a block can finally show a gradient and an image at once. That has been worked around with custom CSS for years. - The Navigation block no longer forces its font size onto nav links and submenus. The old behaviour compounded relative units down nested dropdowns, turning 1.5em into 2.25em into 3.375em.
- Tabs and Playlist blocks are now stable. Tabs in core means one fewer plugin for tabbed content.
- Admin components dropped the 40px opt-in. The
__next40pxDefaultSizeprop is a no-op now; remove it from any custom admin UI.
What we would actually do
Our advice depends entirely on what the site is:
A small business site on mainstream plugins: update a few days after release. Take a backup, click update, spot-check the pages that matter. Risk is low.
An agency or client site with custom blocks or admin columns: staging first, without exception. Test the iframed editor against your custom blocks and check anything touching post list tables.
A store or high-traffic site: wait for 7.1.1 unless you have staging and a tested rollback. There is no prize for being first, and the first point release after a major version always tidies something up.
Whatever the site, confirm you are on 7.0.3 today. The security fixes matter more than any feature in 7.1.
Frequently asked questions
When is WordPress 7.1 released?
19 August 2026, timed to the final day of WordCamp US in Phoenix. Both release candidates have shipped and the feature set is locked, so what is in the RC is what you get.
Should I update to WordPress 7.1 straight away?
It depends on the site. A small business site on mainstream plugins can update within a few days of release after a backup. An agency or client site with custom blocks or custom admin columns should go through staging first. A store or high-traffic site should wait for the first point release unless you have staging and a tested rollback.
What is most likely to break in WordPress 7.1?
Two things. First, post list tables moved the primary row header from the checkbox column to the title column, so plugins with CSS or JavaScript targeting that markup can break. Second, the post editor is now always iframed, which affects older custom blocks still on Block API version 2 or lower.
Does WordPress 7.1 have real-time collaboration?
No. It was cut from 7.0 late in the release cycle and has not returned in 7.1. Notes received the collaboration work instead, gaining email notifications for mentions and shareable revision links. Live multi-author editing remains unresolved.
What are responsive styles in WordPress 7.1?
You can now set styles for tablet and mobile viewports directly in the editor and in theme.json, without writing media queries. Themes can configure their own breakpoints, defaulting to 480px for mobile and 782px for tablet. Blocks using standard block supports get this automatically; blocks with custom style controls do not.
Do I still need to install WordPress 7.0.3?
Yes, and urgently if you have somehow missed it. WordPress 7.0.2 on 17 July fixed one critical and one high severity issue, serious enough that WordPress.org enabled forced updates. 7.0.3 followed on 6 August with about a dozen more fixes. Check Dashboard then Updates.