WordPress 7.1 Beta 1 Is Out: What Agencies Need to Test Before August 19

WordPress 7.1 Beta 1 landed today. If you manage client sites, this is the point in the release cycle where a small amount of testing now saves you a support ticket in five weeks. Final release is August 19, timed with WordCamp US — which gives you roughly a month to find out whether anything you or your clients depend on breaks before it becomes a production problem.

I don't install betas on anything client-facing, but I do keep one throwaway staging environment cloned from our most "typical" client stack — Breakdance, WooCommerce, a handful of common plugins — specifically for this. Twenty minutes today beats an emergency rollback in August.

Release schedule

Anne McCarthy leads the release as Release Lead, with Benjamin Zekavica and Krupa Nanda coordinating; Aki Hamano and Joe Dolson are handling technical guidance. After feature freeze, the team's stated focus shifts entirely to bug-fixing — so what's in Beta 1 and Beta 2 is close to what ships, barring anything that turns out to be actively broken.

This piece covers what's visible to most agencies — blocks, styling, page-builder compatibility. If you build or evaluate AI-powered plugins, the AI Client is also getting streaming responses and semantic search this cycle; see our companion piece on WordPress 7.1's AI Client updates and the WordPress 7.0 AI features guide for the layer underneath it.

What's actually shipping

Responsive and pseudo-state block styling

The block editor gains the ability to style blocks per viewport directly in the interface, plus CSS pseudo-class styling (:hover, :focus, :active) without writing custom CSS. This has been a "you needed a page builder for this" gap in core block styling for a while — worth testing against any client site that leans on native blocks rather than Breakdance or Bricks for layout.

Grid layouts also get auto-fit behavior, and flex children with a fixed width now correctly get flex-shrink: 0, so they stop unexpectedly compressing in flex containers — a small fix, but one that's caused real layout bugs in client builds.

Three new blocks

• Playlist — sequenced audio/video playback in one block.
• Table of Contents — auto-generated, updates as headings change. If you're currently hand-rolling a TOC for long-form content (we do this on 3000+ word guides), this is worth testing as a replacement.
• Tabs — native tabbed content, previously something you'd reach for a plugin or page-builder component to do.

Block Bindings — the API that connects block content to dynamic data sources — also extends to List Items, preserving nested content, and the Icon block picks up flip and rotate controls.

An experimental React 19 flag

Gutenberg 23.4 ships an experimental gutenberg-react-19 flag that swaps the editor's React 18 bundles for React 19 at runtime. It is not the default in 7.1 Beta 1 — it's opt-in, for testing. If you maintain any custom Gutenberg blocks for clients, or a plugin dependency does, this is the signal to start testing against it now rather than waiting for it to become the default in a future release. React major-version bumps have a track record of breaking blocks that use internal editor APIs instead of the documented ones.

Classic block stays

There was an earlier proposal to remove the Classic block from the inserter. It's not happening in 7.1 — the block remains available. If you've got legacy client sites built on Classic-block content that you haven't migrated to blocks, there's no forced deadline here.

Media and REST changes

GIF uploads now generate a video companion file automatically (better performance than serving raw animated GIFs), and HEIC/HEIF uploads are accepted even without server-side editor support for that format — relevant if any clients hand you photos straight off an iPhone, which is most of them. The REST attachment endpoint also picks up output-format, progressive-rendering, and quality fields, and unicode email addresses now work correctly on UTF-8 database sites.

Speculative loading default shifts

The speculative-loading default (prefetching likely next-page navigations) moves from "conservative" to "moderate" when the site has caching in place. This is a quiet performance change most site owners won't notice directly, but if you benchmark Core Web Vitals for clients, it's worth re-running your usual checks after updating rather than assuming nothing changed. See our Core Web Vitals fix checklist for the standard testing routine.

What to actually test before August 19

Don't wait for the final release to find out something's broken. With four weeks of beta and RC cycles available:

1. Clone a representative client site to staging and run the beta against it — not a blank install. Theme/plugin conflicts don't show up on a default Twenty Twenty-Five test site; they show up on the messy real-world stack a client actually runs. Our staging site guide covers the setup if you don't already have a repeatable clone workflow.
2. Check page-builder compatibility. Breakdance and Bricks both interact with the block editor's iframe and styling system in ways that core changes can quietly break. If you run either across your client base, this is the release to actually open the builder on a beta install and click around — see our Breakdance vs Bricks comparison if you're deciding which to standardize on.
3. Test any custom blocks against the experimental React 19 flag, even though it's not default yet. Better to find the breakage in July than to be caught flat when it becomes the default in a later release.
4. Re-run your Core Web Vitals baseline after the speculative-loading default change, especially on sites with aggressive page caching already in place.
5. Leave the Classic block alone if you're using it — nothing forces action here this cycle.

The agency rollout plan

Treat 7.1 like every other major core release, not like a plugin update: staging first, batches second, all-at-once never. When it goes final on August 19:

• Update your own staging/testing environments the same day.
• Roll out to non-critical client sites (brochure sites, low-traffic blogs) within the first week.
• Hold off on e-commerce and high-traffic sites for a second week, watching plugin compatibility reports and the WordPress.org support forums for anything that surfaces once the update hits real-world scale.
• Use a fleet management tool — WP Umbrella or equivalent — to stagger updates across client sites on a schedule instead of one at a time by hand, and to catch anything that breaks post-update before a client does.

Onboarding new clients during this window? Our client onboarding process guide covers where update-management policy fits into that conversation — worth setting expectations about release-cycle timing with new clients now, before 7.1 forces the conversation.

Nothing in 7.1 Beta 1 looks disruptive on paper — it's an incremental release, not a rewrite. But "incremental on paper" and "no plugin conflicts on your actual client stack" are two different claims, and only one of them you can verify by reading the changelog. Clone a staging site this week and find out which one you're dealing with before August 19 does it for you.