WordPress 7.1 RC1 Is Out: Your Beta Testing Just Expired

WordPress 7.1 Release Candidate 1 shipped on August 5, which puts the general release thirteen days out. The number that matters for agencies is not the release date, though. It is 145.

That is how many updates and fixes went in between Beta 4 and RC1 — 57 in the editor, 88 in core. Between one beta and one release candidate. If you ran your compatibility pass during the beta cycle in July, as the release notes asked everyone to, you tested a codebase that has since moved underneath you in 145 places. Those results describe a version of WordPress that is not the one shipping on August 19.

This is the awkward part of the release cycle that nobody schedules time for. The beta testing felt like the work. It was the reconnaissance.

Why RC1 is the milestone that actually matters

Through July, the 7.1 cycle produced four betas in fourteen days: Beta 1 on July 15, Beta 2 on July 17, Beta 3 on July 22, and Beta 4 on July 29. Testing against any one of them told you something useful about direction and very little about specifics, because the next build was a few days away and would change things.

A release candidate is a different proposition. It is the build the project intends to ship, offered for one last round of scrutiny. The remaining schedule is short and fixed:

Read that table as a deadline rather than a timeline. Anything you discover and report before roughly August 11 has a genuine chance of being fixed in RC2. Anything you find on August 17 is going to ship, and your options narrow to holding the update on affected sites.

What changed since Beta 4

The RC1 announcement calls out four things by name.

An Icons API for registering icons and icon collections. If your team maintains custom blocks with inline SVGs scattered through the render functions, this is the sanctioned way to do it, and it is worth a look before you write another one.

Speculative loading configuration via environment variables and constants. This one compounds with a change we covered separately: 7.1 also raises the speculative loading default from conservative to moderate on sites where core detects a caching layer. If you have not audited that yet, the speculative loading write-up is the more urgent read of the two, because the default changes whether you configure anything or not.

Email notifications for @mentions in Notes, and Shareable Revisions — direct links to a specific revision. Both are editorial-workflow features. Neither is likely to break a client site, but both will generate "what is this?" questions from clients the week after the release, which is worth pre-empting.

What the announcement does not describe is the other ~141 changes. That is not a criticism — release notes summarise headline features, not every ticket — but it is precisely why a beta-era pass does not transfer. The features you read about are not where regressions hide. Regressions hide in the 88 core changes nobody wrote a paragraph about.

A dated plan for the next thirteen days

Concrete dates, because "before the release" is how this slips to August 18.

August 6–8 — the risky tier. Every client site with custom blocks, a custom editor configuration, a page builder doing non-standard things, or a plugin known to hook deep into core. Full pass: editor loads, blocks render, save and revision flow works, front end matches. These are the sites where a regression is plausible and where finding it now still leaves time to report it.

August 9–11 — everything else, fast. Smoke test the standard-build sites. Load the editor, edit a post, save it, view it. Ten minutes each. You are looking for the obvious and unexpected, not doing a full audit.

August 12–13 — RC2 lands. Retest only what RC1 flagged, plus anything whose fix you were waiting on. If RC1 was clean across your estate, this is a short day.

August 14–15 — client communication. This is the step agencies skip and then regret. Tell clients the update is coming on August 19, whether you are applying it or holding it, and what you need from them. A three-line email now prevents a client updating on their own on release day.

August 18 — freeze day. No testing worth doing. Confirm your rollout list, confirm your rollback path, confirm someone is actually available on the 19th.

August 19 — release day. Update in tiers. Your own sites first, then low-risk clients, then the complex ones. Not everything at once, and not on a Friday afternoon equivalent.

How to actually run RC1

Four supported routes, and the official note is explicit: do not install or test this on production or mission-critical sites.

The WordPress Beta Tester plugin is the usual choice — install it, then set the channel to "Bleeding edge" and the stream to "Beta/RC Only". For a scripted setup across several staging sites, WP-CLI is faster:

wp core update --version=7.1-RC1

You can also grab the RC1 zip directly, or spin up a throwaway WordPress Playground instance in the browser, which is the quickest way to check whether a specific plugin explodes without provisioning anything at all.

The constraint most agencies hit here is not knowledge, it is environments. Testing thirteen client sites against an RC means thirteen staging environments you can break without consequence, ideally cloned from production so the test means something. If your current host makes that a manual database-export exercise, this fortnight is a reasonable moment to notice that — one-click staging turns this whole exercise from a day of work into an afternoon.

If you find something

Report it, and report it early enough to matter.

Plugin and theme compatibility problems belong in the support forums. Something that looks like a genuine core regression belongs on Trac. In both cases, the useful report is the boring one: what you did, what you expected, what happened, and the smallest environment that reproduces it. "The editor breaks with our theme" gets triaged slowly. "Registering a block with apiVersion: 3 and a custom save throws X, reproduced on a clean install with only plugin Y active" gets fixed.

If you ship plugins or themes yourself, there is a second job: bump the Tested up to value in your readme to 7.1 once you have verified against RC1. The official guidance asks for this during the RC phase specifically, and the reason is timing. Users see that value when they are deciding whether to update. Setting it on August 20th, after the update prompts have already gone out, is a week too late to be useful to anyone.

The short version

RC1 is not a preview. It is the release, offered to you a fortnight early so the bugs get found by people who chose to look rather than by clients on August 19.

The 145 changes since Beta 4 are the argument for spending a few hours on this: they mean your July testing describes a codebase that no longer exists. The retest is far cheaper than the first pass, and it is the difference between knowing your estate is fine and assuming it.

Thirteen days. RC2 on the 12th is your last real checkpoint.

Update: 7.1 "Mary Lou" shipped on August 20. If you are reading this after that date, the testing window has closed — see what actually shipped and what to do this week.