WordPress 7.1 Release Candidate 1 is a test release for a staging or local copy only. Do not install it on a production, customer-facing, or mission-critical website. The current WordPress 7.1 roadmap schedules the stable release for August 19, so this is the right window to find theme, plugin, editor, and workflow issues before a normal production upgrade becomes available.
Keep production on its current supported stable release. This guide helps site owners, editors, agencies, and hosting teams run a controlled compatibility review of the release candidate. It is not a production update procedure.
Set a safe testing boundary
Use a current staging copy or local development site that is separate from production. Give the test a named owner, a time window, and a simple place to record results. Keep real customer data, live payment activity, production emails, and public-facing experiments outside the test environment.
Before changing the WordPress version, record the active theme, plugins, PHP version, important integrations, and the current behavior of the pages that matter. Confirm that the test copy can be restored or rebuilt. The WordPress backup restore test guide can help you validate that recovery work separately; an assumed backup is not a recovery plan.
Update the test copy and check the basics
- Use the current official WordPress testing guidance and apply the release candidate to the approved non-production copy.
- Open the front end and the administration area in a private browser window. Confirm that pages load, sign-in works for the test accounts, and routine editing is available.
- Check the active theme, child theme, page builder templates, custom blocks, and integrations that rely on the editor. Give extra attention to custom work that may depend on older WordPress or Block API behavior.
- Review the site health and plugin notices, but treat a notice as a question to investigate rather than proof that a component is broken.
The official WordPress 7.1 Release Candidate 1 announcement is the primary release note for this test cycle. Recheck it and later release notes before changing a production site; a release candidate can still change before the scheduled stable release.
Test the visitor and business journeys that matter
Do not stop after the dashboard opens. Repeat the actions that make the site useful to visitors and staff. A focused list is usually better than a broad click-through with no record.
- Open the home page, key landing pages, navigation, search, and the contact or lead form.
- Create, edit, preview, and publish a representative post or page. Check the blocks, patterns, templates, comments, notes, and editorial tools your team actually uses.
- Test account sign-in, password reset, membership, booking, course, or client portal flows where they apply.
- For WooCommerce stores, test product editing, cart, checkout in the payment sandbox, customer account access, transactional email handling, and the scheduled tasks that support orders.
- Check the same key pages on a phone-sized viewport and desktop browser. Record obvious layout, accessibility, or performance regressions for follow-up.
When a plugin or theme looks suspect, do not deactivate a group of live components to chase the cause. Use the WordPress plugin troubleshooting guide to isolate one approved variable at a time in the controlled environment.
Record a useful result
For each finding, save the affected workflow, test account type, visible outcome, related component and version, and the smallest repeatable set of ordinary user actions. A screenshot of the visible result is often enough for the owner to understand the issue without collecting or publishing private logs.
Classify the result as passed, needs vendor follow-up, needs custom development review, or needs a production maintenance plan after the stable release. Include a clear owner and next date. This turns release-candidate testing into useful preparation instead of an untraceable experiment.
Wait for the stable release before planning production
A successful release-candidate test is encouraging, not a reason to deploy prerelease software to production. After the stable WordPress 7.1 release, review the final release notes, confirm vendor compatibility statements, select an approved maintenance window, and use the WordPress update safety guide for the production change.
For help organizing the test result, maintenance owner, and next action, start from the FixItPhill WordPress support hub. Keeping testing, recovery, and the eventual production update as separate decisions reduces avoidable downtime.
Official references
- WordPress 7.1 Release Candidate 1 announcement
- WordPress 7.1 roadmap and release schedule
- WordPress developer guidance for the 7.1 cycle
Bottom line: test WordPress 7.1 Release Candidate only on a staging or local copy, measure the real workflows your site depends on, record each finding, and wait for the stable release before scheduling a production update.
