• CodeRevolution
• WordPress

WordPress 7.1 is not the release that puts an AI writing assistant in every dashboard or turns the block editor into Google Docs overnight. Several headline ideas discussed during development—including real-time collaboration and React 19—did not make the final cut.

What WordPress 7.1 does deliver may be more useful in day-to-day work: native responsive styling, editable hover and focus states, browser-based image processing, richer editorial Notes, a proper Tabs block, an interactive Playlist block, a redesigned media editor, and a post editor that behaves more consistently across themes and plugins.

It is also a substantial developer release. The WordPress 7.1 Field Guide counts more than 310 Core Trac tickets, including over 100 enhancements and more than 180 Core bug fixes. The editor side incorporates almost 600 Gutenberg enhancements and more than 630 bug fixes.

That is a large amount of change for a release that can initially look like a collection of interface refinements.

This guide explains what is coming in WordPress 7.1, when it will be released, which features matter most, what developers need to test, and which much-discussed features were postponed.

WordPress 7.1 at a glance

When is the WordPress 7.1 release date?

WordPress 7.1 is scheduled for Wednesday, August 19, 2026. The release dry run is planned for August 18, one day before the final package is made available.

The release is currently at WordPress 7.1 RC3. According to the official RC3 announcement, the build contains more than 90 changes since RC1: 37 editor fixes and 57 Core fixes. RC3 also marks the hard string freeze, so translators can complete language packs against stable interface text.

The schedule shifted slightly because of security releases issued during the 7.1 cycle. RC2 arrived on August 6 as part of WordPress 7.0.3, and RC3 followed the WordPress 7.0.4 security release. The final August 19 date remains unchanged on the official WordPress 7.1 release schedule.

A release candidate is close to the finished version, but it is not a production update. Critical bugs, security fixes, and packaging changes can still land before August 19. Site owners should wait for the final release, while plugin and theme developers should use RC3 on local or staging installations now.

One additional point matters for security-conscious site owners: do not wait for WordPress 7.1 to receive a security fix that is already available in the current stable branch. If your dashboard offers WordPress 7.0.4, install that security update now and treat 7.1 as a separate major-version upgrade.

The short version: what is new in WordPress 7.1?

WordPress 7.1 improves four areas more than any others.

First, block-theme designers gain responsive and state-based controls that previously required custom CSS. A block can have different spacing or typography on desktop, tablet, and mobile, while Buttons and Navigation Links can define hover, focus, and active styles.

Second, WordPress begins processing supported media in the visitor’s browser before sending the generated sizes to the server. This can reduce server memory pressure and make modern image formats available on hosts that lack the necessary image libraries.

Third, collaboration inside the editor becomes more practical. Notes can attach to selected text, span multiple blocks, contain limited rich text, support multiple conversations, and notify mentioned users.

Finally, WordPress 7.1 strengthens the platform beneath plugins and themes. The post editor is now always loaded in an iframe, the Abilities API gains more execution hooks, SVG icons receive a standardized registration API, and several editor data packages continue moving toward stable application-building tools.

Let us look at those changes in detail.

Responsive block styling finally becomes a Core feature

Responsive editing is arguably the most important visual change in WordPress 7.1.

Until now, a block’s visual settings generally applied to every screen size. Theme developers could create responsive rules in CSS, and some third-party block plugins supplied device-specific controls, but WordPress Core did not provide a consistent way to edit responsive values.

WordPress 7.1 adds tablet and mobile styling directly to the editor. When responsive editing is enabled, a user can switch the preview to a smaller viewport and change supported settings for that breakpoint. The mobile adjustment is stored separately instead of replacing the desktop value.

The system covers block supports including typography, colors, backgrounds, borders, dimensions, spacing, and layout. Exact controls still depend on what a block and theme expose, so every block will not necessarily display every responsive option.

The default viewport ranges are:

Theme authors can change the mobile and tablet thresholds in theme.json. WordPress uses the desktop or base value as the default; there is no separate @desktop key.

Here is a simplified example of a Group block with responsive padding:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "viewport": {
      "mobile": "30rem",
      "tablet": "48rem"
    }
  },
  "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"
            }
          }
        }
      }
    }
  }
}

The implementation is more than an editor convenience. It gives themes, blocks, Global Styles, and individual block instances a common responsive model. That should reduce the need for plugins to invent proprietary device controls and generate their own media queries.

Agencies should still decide how much control clients need. WordPress provides a responsiveEditingEnabled setting that can hide the responsive editing interface while preserving responsive styles already saved in content. The responsive block styles developer note explains the schema, supported units, serialization, and opt-out behavior.

Hover, focus, and active states without custom CSS

WordPress 7.1 also introduces a formal way to style interactive states.

In the Site Editor, designers can configure hover, focus, focus-visible, and active appearances for supported blocks. A Button might use a darker background on hover, a visible outline during keyboard focus, and a pressed state while being activated. These rules can be applied globally or, for Buttons, to an individual block instance.

Buttons and Navigation Links are the first Core blocks to support these states at the theme level. The editor’s per-instance controls are narrower at launch, so users should not assume that every block exposes a state selector.

This is a meaningful accessibility improvement as well as a design feature. Keyboard focus should never be treated as an afterthought. A clear :focus-visible style helps keyboard users understand where they are on the page without forcing designers to maintain a separate stylesheet.

Theme developers can define the states in theme.json using keys such as :hover, :focus, :focus-visible, and :active. They can also nest state rules inside responsive rules. WordPress 7.1 additionally supports a theme-level -current state for Navigation Links, although that state is not presented as an end-user control. Full implementation details are available in the pseudo and custom style states developer note.

Together, responsive styles and interactive states close two of the most obvious gaps between native block-theme tools and visual page builders.

WordPress can process images in the browser

WordPress 7.1 changes what happens during a supported media upload.

Traditionally, the browser sends the original file to WordPress and the server asks PHP, GD, or Imagick to rotate the image and create each registered thumbnail size. Large source files can consume considerable server memory. On constrained hosting, this is one reason an upload can succeed while thumbnail generation fails.

With client-side media processing, WordPress can use WebAssembly and wasm-vips to decode, resize, rotate, convert, and encode images inside the user’s browser. The generated sizes are then uploaded individually. If one transfer fails, it can be retried without restarting the complete operation.

The feature can provide several practical benefits:

• less CPU and memory work on the web server;
• support for formats such as AVIF even when the host lacks server-side AVIF processing;
• HEIC conversion for photos from supported devices;
• more consistent output through libvips;
• preservation of Ultra HDR gain-map information; and
• companion MP4 or WebM files for suitable animated GIF uploads.

This is not an all-or-nothing compatibility change. WordPress checks the browser and device before using the client pipeline. The complete workflow is initially available on recent Chromium-based browsers, while unsupported browsers fall back to normal server-side processing. Safari can still provide limited HEIC decoding support. Devices with insufficient memory or processing capacity also use the server route.

That fallback is important. WordPress 7.1 does not suddenly make Imagick or server-side image support irrelevant, and an agency should test uploads in the browsers its editors actually use.

Plugin developers have more work to do. Code that relies exclusively on server-side image-editor hooks may not run when the browser creates the derivatives. Sites with a strict Content Security Policy may need to allow blob workers, and external scripts loaded into cross-origin-isolated editor screens may require compatible CORS attributes. The client-side media processing developer note documents the browser requirements, hooks, quality controls, fallback behavior, and security headers.

If your plugin modifies upload quality, adds custom image sizes, attaches metadata, or sends media to an external storage service, this is one of the first WordPress 7.1 workflows you should test.

A more capable media editor and smarter galleries

Client-side processing is only one part of the media work in WordPress 7.1.

The release adds a new Media Editor modal that can be opened from Image, Cover, and Site Logo blocks. It brings cropping, rotation, flipping, zooming, and metadata editing into a more consistent interface. Editors no longer need to leave the content flow for common image adjustments.

Galleries can also become dynamic. A Gallery block can display media attached to the current post rather than relying only on a manually selected static set. This is especially useful for portfolios, event recaps, property listings, and other content types where uploaded images naturally belong to one entry.

The media library continues receiving smaller usability improvements too, including revised browsing behavior and better handling of large collections. These changes are less visible in a feature list, but they address workflows editors repeat every day.

Notes become useful for real editorial review

WordPress introduced Notes as the foundation for in-editor feedback. WordPress 7.1 turns that foundation into a more credible editorial tool.

A note can now attach to a selection of words rather than only an entire block. It can span multiple blocks, and a single block can contain more than one independent conversation. Long notes gain a show-more control, while limited rich text supports bold, italic, links, and inline code.

The other major addition is @mentions. Editors can mention another WordPress user in a Note, and WordPress can send an email notification to bring that person into the conversation. A convenient toolbar action makes starting a Note easier, while shareable revision links improve the broader review process.

These changes make Notes suitable for copy edits, legal review, design feedback, and client approval without pushing every comment into email or an external document.

There is an important distinction: enhanced Notes are not the same as real-time collaboration. Multiple people are not simultaneously editing the same post with live cursors in WordPress 7.1. The collaboration work is progressing, but the real-time editing interface was not enabled for this release.

Two genuinely useful new Core blocks

WordPress 7.1 adds two blocks that many sites previously obtained from block libraries or custom development.

Tabs block

The new Tabs block creates an accessible set of tabs and associated content panels. Editors can add, remove, and reorder tabs while WordPress keeps the labels and panels synchronized. The result includes the keyboard and screen-reader behavior expected from a proper tab interface.

This is an important point because tabs are easy to make visually and surprisingly easy to make inaccessible. A Core implementation gives theme and plugin authors a shared structure instead of dozens of incompatible versions.

Tabs are useful for product specifications, pricing explanations, service details, FAQs, documentation, and any interface where several related content panels need to fit into a compact space. They should still be used selectively: hiding essential content behind several tabs can make a page harder to scan.

Playlist block

The Playlist block groups multiple audio files into an interactive player with a track list and waveform. It gives podcasters, musicians, course creators, and publishers a native way to present an ordered audio collection without embedding a third-party player.

As with any media interface, test keyboard operation, mobile layout, preload behavior, and the total weight of the audio files before using it on a high-traffic page.

Existing blocks receive practical upgrades

Several smaller block changes are likely to appear in more sites than either new block.

Background gradients can now be layered with background images on supported blocks instead of forcing the editor to choose one or the other. The change applies across containers and content blocks including Group, Cover-related layouts, Quote, Pullquote, Verse, Accordion, and Post Content where supported.

The Image block gains a Mark as decorative option. When an image adds visual atmosphere but no information, an editor can mark it so assistive technology does not announce it. This is clearer and safer than expecting every content author to understand how an empty alternative-text value should be used.

Custom HTML becomes less opaque. Supported nested blocks can remain editable while the block is viewed in its preview mode. Embed and Shortcode blocks also receive smarter transforms, making it easier for WordPress to recognize content that belongs in a more specific block.

Block Bindings expand into additional content structures, including list items, giving developers more options for connecting block output to post meta or other data sources.

None of these changes deserves a release on its own. Together, they remove a noticeable amount of friction from native block-building workflows.

The Site Editor and post editor feel more connected

WordPress 7.1 continues the slow consolidation of interfaces that previously felt like separate products.

The admin toolbar now remains visible in both the Post Editor and Site Editor. When a Site Icon is configured, it can replace the generic home icon, the profile avatar uses a circular treatment, and the toolbar follows the user’s selected admin color scheme. The command palette remains available with Cmd/Ctrl + K, even though its former toolbar icon has been removed.

The Site Editor itself also reflects the selected admin color scheme around the editing canvas. The canvas stays white so the site’s content does not inherit interface colors.

A new Design → Identity area brings the Site Title, Tagline, Logo, and Site Icon together. Changes to the title and tagline update the preview, reducing the need to move between the Site Editor and Settings for basic brand details.

The command palette is divided into Suggestions, Recent, and Results sections, with recent commands retained for quicker reuse. Visual revisions are clearer, and applying a changed block style globally now opens a review step so the user can decide which properties should be promoted to the global design rather than accepting every difference.

There are thoughtful admin refinements outside the editors as well. Untitled posts can show an excerpt in the Posts list, and a comment can be assigned to another post from its edit screen. These are modest changes, but they reduce ambiguity in content-heavy installations.

Accessibility improvements—and one compatibility warning

Accessibility work in WordPress 7.1 reaches the editor, media tools, and administration screens. In addition to decorative images, accessible Tabs, and editable focus states, Core includes dozens of tickets addressing semantics, labeling, keyboard behavior, and shared interface components.

The most important compatibility change is in WordPress admin list tables.

In screens that list posts, pages, and custom post types, the checkbox cell changes from a row header (th) to a regular table cell (td). The title cell becomes the semantic row header with th scope="row" and receives an accessible label based on the title. This lets screen readers identify a row by its primary object instead of announcing the checkbox column as though it described the content.

The new structure is more accurate, but plugins can break if their CSS or JavaScript assumes that the checkbox is always a th or the title is always a td. A selector such as td.column-title is more fragile than .column-title, and DOM traversal based on tag names should be audited.

Plugin authors should support both the old and new markup if their extension remains compatible with earlier WordPress versions. Site owners should pay particular attention to SEO, editorial workflow, translation, commerce, and custom-field plugins that add controls or columns to post list screens.

The public-facing theme is unlikely to be affected because this change occurs in wp-admin, but a broken admin workflow can still stop editors from publishing. We covered the broader modernization path in How to Modernize Classic PHP Meta Boxes for the WordPress 7.x Sidebar.

The post editor is now always rendered in an iframe

For developers, the always-iframed post editor may be the most consequential WordPress 7.1 change.

WordPress 7.0 loaded the post editor in an iframe only when the blocks in the current content met specific Block API requirements. That meant the editor environment could change depending on the theme, installed blocks, or even the post being edited.

WordPress 7.1 removes that conditional behavior. The post editor uses an iframe regardless of the theme type, registered Block API versions, content, or presence of legacy meta boxes. The goal is a predictable canvas, stronger style isolation, and more consistent behavior between the post and site editors.

Most modern blocks already work correctly. Problems arise in extensions that assume the canvas shares the parent page’s global window or document. JavaScript that queries the global document for a block’s DOM element may now search the wrong document. Event listeners, portals, measurements, styles, and third-party libraries can fail for the same reason.

The correct document should be derived from the relevant element through ownerDocument, and its window through ownerDocument.defaultView. React-based editor extensions can use WordPress utilities designed to run effects against the correct element context.

Legacy meta boxes are not automatically removed, but plugins that mix a PHP meta box with JavaScript access to the block canvas require careful testing. The official iframed editor developer note provides migration examples and a list of common failure patterns.

Abilities API improvements prepare WordPress for automation and AI

The Abilities API, introduced in WordPress 6.9, provides a machine-readable way for plugins to describe actions WordPress can perform. An ability can declare its input, output, permission logic, and execution callback. That makes capabilities easier to discover and invoke consistently from automation tools, REST-based applications, and AI-oriented integrations.

WordPress 7.1 expands that foundation with ability filtering, client-compatible JSON Schema preparation, a unified public-exposure flag, and new filters at key points in the execution lifecycle. Developers can intervene before execution, normalize input, modify a permission result, or filter the final output. The Abilities API execution filters note documents the new hooks.

This matters to agencies building controlled automation. An integration can expose a narrowly defined action—such as generating a draft, retrieving a product record, or scheduling a review—without giving an external system unrestricted access to WordPress internals.

WordPress 7.1 also continues work around the Core AI Client and connector authentication. However, site owners should understand the boundary: WordPress 7.1 does not add a visible AI assistant, chatbot, or automatic content generator to the default dashboard. The release improves APIs that plugins can use to connect models and abilities. It does not silently send site content to an AI provider.

That platform-first approach is preferable to baking one vendor or model into Core. It gives developers room to connect hosted services or self-hosted models while keeping authentication, permissions, logging, and user consent inside the plugin’s control.

A standardized SVG Icon API

Plugins have historically handled icons in several different ways: bundled image files, inline SVG strings, Dashicons, custom icon components, and copied markup. WordPress 7.1 introduces a public SVG Icon API to make registration and rendering more consistent.

Developers can register icons and icon collections, expose them to editor interfaces, and render a registered icon in PHP. Core handles namespacing and SVG sanitization, which is particularly important because arbitrary SVG markup can contain unsafe elements or attributes.

The API does not mean every plugin should ship a massive icon pack. It means blocks and admin applications can refer to a common, registered asset instead of repeatedly embedding uncoordinated SVG. The official SVG Icon API guide includes the JavaScript and PHP registration patterns.

DataViews, the Design System, and other developer changes

WordPress 7.1 advances the packages used to build modern administration screens. DataViews, DataForm, and View Config receive new capabilities and refinements, including more flexible actions and improved selection behavior. These packages are increasingly relevant to plugin developers who want WordPress-native tables, grids, forms, filters, and data-management interfaces without recreating the entire UI stack.

A ThemeProvider and token work from the emerging WordPress Design System also land as foundations for more consistent application interfaces. This is not a complete redesign of wp-admin, but it gives Core and plugin projects a more coherent path for colors, spacing, typography, and components.

Other compatibility items include an update to jQuery UI 1.14.2 and performance work in template discovery for themes with large template collections. Developers should read the relevant sections of the WordPress 7.1 Field Guide rather than relying only on the user-facing release highlights.

What did not make it into WordPress 7.1?

Early roadmap discussions and beta coverage created understandable confusion about the final scope. Four notable items are not part of the completed WordPress 7.1 release.

Real-time collaboration

WordPress 7.1 improves Notes and revision sharing, but concurrent editing with live cursors is not enabled. The underlying collaboration work continues and may appear in a future major release when its storage, conflict resolution, permissions, and interface are ready for broad use.

React 19

The React 19 upgrade was tested experimentally in the Gutenberg plugin but was deferred beyond WordPress 7.1. Plugins should continue testing modern React compatibility, but Core’s production dependency does not make that major jump in this release.

The “On This Day” dashboard widget

A proposed dashboard widget for resurfacing older content did not make the release. Any screenshots or previews showing it should not be treated as a WordPress 7.1 feature.

Hiding the Classic block

A proposal to remove the Classic block from the normal inserter was reverted. The block remains available in WordPress 7.1. This does not reverse the broader move toward blocks; it simply avoids disrupting established content workflows in this release.

This distinction between roadmap and release is why the RC Field Guide matters. A roadmap describes intended work. The release candidate shows what actually survived development, testing, and scope decisions.

Will WordPress 7.1 break plugins or themes?

Most well-maintained sites should update normally, but WordPress 7.1 has several changes that deserve more than a quick front-page check.

The highest-risk areas are editor extensions that access the canvas through the global document, media plugins that depend on server-only processing hooks, admin tools that target th or td elements in list tables, block themes with their own responsive-style implementation, and plugins that bundle or restyle jQuery UI components.

The release also changes enough editor behavior that custom blocks should be tested when inserted, edited, duplicated, transformed, saved, and reloaded—not merely rendered on the front end.

A sensible compatibility matrix looks like this:

The release candidate period exists specifically for this work. Developers who wait until August 19 to open their plugin in WordPress 7.1 are using customers as their compatibility test.

How to test WordPress 7.1 RC3 safely

Do not install RC3 on a production site. Use a disposable WordPress Playground instance, a local development environment, or a staging copy with production-like content and plugin settings.

The easiest graphical route is the WordPress Beta Tester plugin. On a test site, choose the Beta/RC channel, save the setting, and install the offered 7.1 release candidate from Dashboard → Updates.

Developers can use WP-CLI from the root of a non-production WordPress installation:

wp core update --version=7.1-RC3

After updating, enable debugging, review the PHP error log, and keep the browser console open. Test with the actual roles used on the live site—not only an administrator account. An editor, author, shop manager, or custom role can expose permission and interface problems that an administrator never sees.

The official WordPress 7.1 testing guide provides scenarios for Notes, responsive styling, media, the new blocks, revisions, admin changes, and accessibility.

A practical WordPress 7.1 update checklist

Once the final release is available, resist the temptation to treat a major update like a routine cache purge. A short, repeatable process is faster than recovering from an avoidable production problem.

1. Confirm that a current, restorable backup includes both files and the database.
2. Update active plugins and the theme before testing WordPress 7.1.
3. Clone the live site to staging with the same PHP version and important server settings.
4. Install WordPress 7.1 on staging and clear page, object, CDN, and browser caches.
5. Test login, publishing, revisions, scheduled posts, forms, checkout, search, and role-based access.
6. Upload large JPEG, PNG, WebP, AVIF, and HEIC files relevant to your editorial workflow.
7. Open custom blocks and legacy meta boxes, then check the browser console for iframe-related errors.
8. Review post, page, product, order, and custom-post-type list tables.
9. Inspect representative pages at desktop, tablet, and mobile widths for unexpected responsive rules.
10. Run the production update during a monitored maintenance window and verify the critical paths again.

For a brochure site with a standard theme and a small plugin stack, that process may take 20 minutes. For WooCommerce, membership, multilingual, learning-management, or editorial installations, it deserves a formal test plan.

Should you update to WordPress 7.1 immediately?

Most site owners should install the final WordPress 7.1 release after completing a backup and a brief staging test. The responsive tools, media improvements, accessibility fixes, and accumulated bug fixes make it a worthwhile upgrade.

There is no advantage in installing RC3 on a live site. A release candidate is for compatibility work, bug reports, and advance testing. Wait for the final build on August 19 unless you maintain a plugin, theme, hosting platform, or test environment.

Agencies managing many sites may prefer a staged rollout. Start with internal and lower-risk installations, monitor logs and support reports, then move to commerce and mission-critical sites. That is normal release management, not a reason to avoid 7.1.

If a critical plugin has not declared compatibility, check its changelog and support channel. “Tested up to” metadata is useful, but your own staging test is stronger evidence because it includes your content, configuration, server, and plugin interactions.

Frequently asked questions about WordPress 7.1

What is the WordPress 7.1 release date?

WordPress 7.1 is scheduled for August 19, 2026. The date remains official as of RC3 on August 12, although any software release schedule can change if a critical issue is discovered.

Is WordPress 7.1 available now?

WordPress 7.1 RC3 is available for testing. It is not the final production release. Use WordPress Playground, a local site, or staging if you want to test it before August 19.

What are the biggest new features in WordPress 7.1?

The most significant user-facing additions are responsive block styling, hover/focus/active state controls, client-side media processing, richer Notes with mentions, a new media editor, and the Tabs and Playlist blocks. Developers also gain an always-iframed post editor, Abilities API improvements, and a standardized SVG Icon API.

Does WordPress 7.1 include real-time collaboration?

No. Notes and revision sharing are improved, but WordPress 7.1 does not enable simultaneous Google Docs-style editing or live collaborator cursors.

Does WordPress 7.1 add artificial intelligence to the dashboard?

No. Core continues to improve AI- and automation-related foundations, including the Abilities API and connector work, but WordPress 7.1 does not ship a default chatbot, writing generator, or model connection for site owners.

Does WordPress 7.1 remove the Classic Editor or Classic block?

No. The Classic block remains available. A proposal to hide it from the normal inserter did not ship. The separate Classic Editor plugin is not removed by this release.

Will WordPress 7.1 require a block theme?

No. Classic and hybrid themes continue to work. Block themes benefit most directly from the new Site Editor and theme.json capabilities, but WordPress 7.1 does not require every site to switch themes.

Can WordPress 7.1 process AVIF and HEIC images without Imagick?

On compatible browsers and devices, the client-side pipeline can process several modern formats before the files reach the server. Unsupported environments fall back to server-side processing, so actual behavior depends on the browser, device, host, and installed media plugins.

Is WordPress 7.1 a security release?

It is a major feature release that also includes the security fixes present in the latest stable packages. Site owners should not postpone an already available security update while waiting for 7.1.

WordPress 7.1 is a foundation release with visible benefits

WordPress 7.1 does not hinge on one spectacular feature. Its value comes from removing recurring limitations.

Designers can create responsive layouts and interaction states without dropping into custom CSS. Editors get better feedback tools, media editing, navigation, and two long-needed blocks. Hosts may see less image-processing pressure. Plugin developers receive clearer APIs for abilities, icons, data applications, and editor integration.

The same foundational changes create the release’s main risks. Browser-side media processing changes where code runs. The always-iframed editor exposes extensions that depend on the wrong document. More semantic list-table markup can reveal brittle selectors. Those are solvable compatibility issues, but they reward early testing.

The best plan is straightforward: update the current stable branch for security now, test WordPress 7.1 RC3 away from production, and prepare a staged rollout for the final release on August 19.

WordPress 7.1 may not be the collaboration or AI release some people expected. It is something more immediately useful: a broad upgrade to the way WordPress sites are designed, edited, extended, and maintained.