The announced RC1 schedule is September 10. Prepare the baseline now, verify actual availability, and test the candidate without treating it as a final release.
Quick answer
As checked on September 10, 2026, the published WordPress schedule targets 7.1.1 RC1 for September 10 at 17:30 UTC and the general release for September 17 at 15:00 UTC. Those are announced targets, not proof a package is already available. Prepare a WordPress 7.1 staging baseline now, verify the actual release announcement, and test the confirmed candidate against the same plugin, theme, and customer workflows.
Do not turn a scheduled candidate into a production update
A release candidate is intended for testing before the final maintenance release. The schedule can change and individual fixes can move to a later milestone. Check the official announcement and build identifier when you begin. Do not construct a download URL or assume a nightly build is the exact RC package because the calendar date has arrived.
Keep the test environment separate from live payments, customer messages, and production integrations. A staging clone may inherit working provider credentials, so verify the environment destinations before running checkout or form fixtures. Preserve a restorable database and files snapshot. The useful output is a decision supported by evidence about your site, not a claim that every plugin is compatible.
Capture a baseline that can be compared fairly
Record the WordPress version, active plugins, theme and child-theme versions, PHP runtime, database version, object-cache setup, and relevant feature flags. Keep the same fixture data and configuration for both builds. A changed plugin version or a cache purge can improve a result independently of the core candidate.
Run your critical journeys on WordPress 7.1 first. Include editing and saving a representative page, viewing it while logged out, sending a form to a test destination, searching, logging in, and completing a sandbox checkout if the site sells products. Record any existing failures. Without that baseline, a longstanding problem can be incorrectly reported as a new 7.1.1 regression.
Illustrative diagnostic worksheet. Values are examples, not measurements from a customer site.
Select tests from the actual fix list
The schedule describes a maintenance release focused on issues from the 7.1 cycle. Review the confirmed tickets and editor changes when the candidate is announced. Map each relevant change to a component your site uses. If a fix touches an editor path, use the actual block, theme, and plugin combination affected by that path instead of only opening a blank editor.
Keep a separate small set of business-critical smoke tests even when no listed fix appears to touch them. Shared core behavior can affect integrations indirectly. Prioritize forms, checkout, account access, scheduled processing, and content publishing according to the site purpose. Assign an owner to each test and write the expected result before running it.
Compare changed behavior and collect useful evidence
Install the verified candidate on staging through an official testing route and record its exact version. Run the same fixtures in the same order. Compare stored data, visible output, error logs, and the relevant network responses. Use a fixed cache state for performance comparisons and do not claim speed gains from a single warm request.
When something changes, reduce it to the smallest reproducible case. Record the baseline result, candidate result, steps, expected behavior, and redacted evidence. Test whether restoring the baseline removes the new failure. That comparison is much more useful to maintainers than a generic statement that the site broke after updating. Do not disable every plugin on production to perform this isolation.
Make a release decision after testing
A passing staging test means the chosen fixtures passed on the recorded build and environment. It does not preapprove a later candidate or final package with additional changes. Recheck the final release notes, repeat affected tests, and choose a deployment window with rollback and monitoring available. Keep the record concise enough that another operator can repeat the same checks.
If RC1 is not yet available, leave candidate results pending and retain the prepared baseline. If a blocking regression remains, report it through the appropriate project channel with reproducible evidence and follow the fix status. Do not publish invented pass results or label a planned date as a completed release. The next useful step is determined by the actual build and test outcome.
Working example
Use this as a read-only starting point or an evidence worksheet. Replace example identifiers with the approved staging fixture.
# Read-only baseline commands on staging
wp core version --extra
wp plugin list --format=json
wp theme list --format=json
# Record PHP from Site Health as well.
# Install only the officially announced candidate.
Before closing the work
- Candidate build is recorded accurately.
- Existing failures are separated from regressions.
- Critical customer journeys have evidence.
- Production remains on an approved stable release.
For help applying these checks to a live site, HandL WP WordPress support can review the affected configuration and verify the result. Continue with WordPress 7.1 iframe editor asset tests when that adjacent issue matches your evidence.
Helpful references