WordPress 7.1 is scheduled for release on August 19, 2026, timed to land on the final day of WordCamp US in Phoenix. Release Candidate 1 went out on August 5 with more than 145 fixes since Beta 4, and the core team has been explicit that RC builds are for test servers only, not production sites. If you host a WooCommerce store or a client site that can’t afford a broken checkout, that warning is worth taking literally rather than treating it as boilerplate.
The Editor Finally Stops Fighting Custom CSS
The headline change is that responsive styling and interactive states (hover, focus, active) become real editor controls instead of something you had to hand-code. Anyone who has maintained a WordPress site knows the workaround: a client wants a button that changes color on hover, and unless a theme or plugin already exposes that option, you’re writing a small CSS snippet and hoping the next theme update doesn’t clobber it. WordPress 7.1 moves that into the block editor UI directly, which means fewer of those one-off snippets scattered across a site’s custom CSS panel, and fewer support tickets when a theme update wipes them out.
This matters more for small business sites than it sounds. A lot of AllCloudHost’s WordPress customers aren’t running a dev agency behind their site. They’re a shop owner or a consultant who built their own site and occasionally needs a small visual tweak. Every bit of styling that moves from “ask a developer to write CSS” to “click a toggle in the editor” is real time saved, even if it never shows up in a changelog headline.
Notes Gets Genuinely Collaborative
WordPress 7.0 introduced Notes as a way to leave asynchronous comments inside the editor. 7.1 extends it with @mentions, email notifications when you’re tagged, multiple discussion threads on the same piece of content, and rich formatting inside notes themselves. For a single-author blog this is irrelevant. For any site with more than one editor, an agency managing several clients, or a business with a marketing person and a copy reviewer, it closes a real gap: right now, most of that back-and-forth happens in Slack or email, disconnected from the actual draft. Bringing it into the editor means feedback stays attached to the specific paragraph it’s about, so nobody has to scroll through a chat thread six weeks later trying to remember why a paragraph was flagged.
Two Smaller Features Worth Knowing About
Two additions in 7.1 are easy to miss next to the editor and Notes changes, but they solve real, specific annoyances. The first is a new Icons API, which lets plugins register icons and icon collections directly in Core rather than every plugin shipping its own icon font or SVG sprite sheet. For site owners this mostly shows up as smaller, more consistent-looking plugin interfaces rather than a mismatched pile of icon styles across the dashboard. The second is Shareable Revisions: a direct link to a specific past version of a page or post, which sounds minor until you’ve tried to explain to a client over email which exact revision from three weeks ago you’re talking about. Being able to just send a link removes that entire back-and-forth.
Media Handling Gets a Quiet but Useful Upgrade
The release also ships a new built-in image editor and smarter media handling, including native HEIC support (the format iPhones default to) and uploads that pause on a dropped connection and resume automatically instead of failing outright. HEIC support alone will save some site owners a genuinely annoying step: right now, a lot of people either don’t realize their phone photos won’t upload directly to WordPress, or they’ve built a habit of converting every image to JPEG first. That workaround disappears once 7.1 lands, assuming your host’s PHP build has the image libraries needed to process HEIC files (most modern hosting stacks do, but it’s worth a quick check if you’re on an older shared plan).
Two New Blocks: Playlist and Tabs
WordPress 7.1 stabilizes two blocks that have been in Gutenberg for a while: Playlist and Tabs. Tabs is the more broadly useful one. It lets you build tabbed content sections (product specs, FAQ categories, service comparisons) natively, without a third-party plugin. If your site currently uses a plugin purely to get tabbed content, this release is a reasonable moment to test whether the native block covers your use case and whether you can drop a dependency you no longer need, which also means one fewer plugin that needs security updates going forward.
The Backend Changes That Won’t Make Headlines But Will Matter
Buried in that count of 145 fixes since Beta 4 (57 in the editor, 88 in Core) are several changes that won’t show up in any marketing screenshot but are worth knowing about if you run more than one site or a multisite network. WordPress 7.1 updates the bundled jQuery UI library to version 1.14.2. That sounds like housekeeping, but any plugin or custom theme still calling an older jQuery UI method that got removed or renamed between versions can break silently after the update, with no error message pointing at the real cause. If your site relies on an older, infrequently-updated plugin for date pickers, sliders, or accordions (jQuery UI’s classic use cases), it’s worth testing that specific plugin against a staging copy running RC1 before August 19, rather than assuming a jQuery UI version bump is purely cosmetic.
Multisite networks get a narrow but real security tightening too: upload size limits are now enforced during media sideloading, not just on direct uploads through the media library. Sideloading is how WordPress pulls in images from external URLs, for instance when a block or plugin fetches a remote image and adds it to the media library automatically, and that path previously could bypass a network’s configured upload limit entirely. For a multisite install where sub-sites have deliberately restrictive upload quotas, this closes a gap rather than just tidying code.
For anyone editing content daily, the more noticeable backend change is that REST API requests get preloaded when the editor loads, which should make opening a post or page for editing measurably faster on a slower connection or a shared hosting plan without much server-side caching in front of the admin area. It’s a small change with an outsized effect on a metric people actually feel: how long the spinner sits there before typing can start.
The Classic Block Isn’t Disappearing After All
If you’ve seen chatter suggesting the Classic block was finally getting removed from the block inserter, that’s not what’s shipping in 7.1. The Classic block stays available as a standard inserter option, a reversal from earlier roadmap discussion about phasing it out. That matters for a specific, real category of WordPress site: one built years ago on a shortcode-heavy or hybrid workflow that never fully migrated to blocks, where a handful of pages still rely on Classic-block-wrapped shortcodes or raw HTML to function correctly. If a site (yours or a client’s) falls into that category, 7.1 doesn’t force a migration deadline the way removal would have. It’s one less thing to triage before the 19th.
What to Actually Do Before August 19
The practical advice from the WordPress core team is straightforward: don’t install RC1 or any pre-release build on a live site. If you want to see 7.1 before it ships, use WordPress Playground, a browser-based test environment that needs no server setup at all, or spin up a staging copy of your site if your host offers one. If you manage a site with custom plugins or an older theme, this window between RC1 and the August 19 release is the right time to check the plugin changelog for a “tested up to 7.1” update, particularly for anything that touches the block editor or custom CSS, since those are the areas most likely to interact with the new responsive-style controls. It’s also worth flagging any custom CSS snippets your team added specifically to handle hover states or responsive breakpoints; once 7.1 ships, some of those may become redundant, and running both the old CSS and the new native controls at once can produce visual conflicts that are annoying to debug after the fact.
For anyone still weighing whether their current WordPress hosting setup makes staging and safe testing easy, a release like this is a decent forcing function to check. If updating your site means editing files over FTP and hoping for the best, that’s a bigger risk than any single WordPress release, and it’s worth fixing before the next major version ships rather than after something breaks.