WordPress 7.1 Release Candidate 3 is now available for testing, placing the next major WordPress release one week away from its planned 19 August 2026 launch. The new build appears in WordPress.org’s official release archive with downloadable ZIP and tar.gz packages.
Key takeaways
- WordPress 7.1 RC3 was published on 12 August 2026.
- The final WordPress 7.1 release is currently targeted for 19 August.
- RC3 is intended for testing and should not be installed on a production website.
- Plugin, theme and hosting teams should use this final testing window to check compatibility.
What WordPress 7.1 RC3 means
A release candidate is a pre-release build that may become the final version if testing does not uncover blocking problems. RC3 does not mean WordPress 7.1 is ready for ordinary production websites. It means the project is concentrating on stability, compatibility and last-minute fixes rather than introducing broad new features.
The official WordPress release archive lists WordPress 7.1 RC3 on 12 August. It follows RC1 on 5 August and RC2 on 6 August. WordPress’s 7.1 release schedule places the dry run and 24-hour code freeze on 18 August, followed by the planned final launch on 19 August.
| Milestone | Date | Status |
|---|---|---|
| Release Candidate 1 | 5 August 2026 | Released |
| Release Candidate 2 | 6 August 2026 | Released |
| Release Candidate 3 | 12 August 2026 | Released |
| Dry run and code freeze | 18 August 2026 | Scheduled |
| WordPress 7.1 final | 19 August 2026 | Target date |
What site owners and developers should test
The most useful RC testing is not simply opening the dashboard. Test the same actions that matter on a real website, but do so on a staging copy or disposable local installation.
- Editing: create, update, preview and schedule posts using the Block Editor.
- Theme compatibility: inspect templates, menus, Global Styles and responsive layouts.
- Plugin compatibility: test forms, SEO tools, caching, backups, ecommerce and membership workflows.
- Media: upload, crop and reuse images and videos in common formats.
- User roles: verify that authors, editors and administrators retain the expected permissions.
- Performance: compare important front-end pages and dashboard workflows with the current stable release.
Before testing, create a restorable backup of the staging database and files. A release candidate can still contain bugs, and third-party plugins may not yet declare compatibility with WordPress 7.1.
WordPress 7.1 features worth watching
The project’s WordPress 7.1 roadmap describes work across collaboration, editing, media, customization and developer APIs. Because the roadmap is a planning document, not every proposed item should be treated as guaranteed until final release documentation confirms it.
More useful collaboration tools
WordPress has been expanding Notes for editorial feedback, including richer discussions and suggestion-oriented workflows. These changes are especially relevant to sites where writers and editors review content together.
Responsive and interactive styling
The 7.1 cycle has focused on giving users more control over how blocks look at different screen sizes and in states such as hover or focus. The aim is to reduce the need for custom CSS for common design adjustments.
Media workflow improvements
Media work includes a dedicated editor experience and continued improvements to client-side processing. Testers should pay attention to image cropping, rotation, metadata, upload reliability and browser compatibility.
Changes for plugin and theme developers
The cycle also includes work on editor components, block APIs, DataViews, the Abilities API and other developer-facing systems. Extension authors should test their products now rather than waiting for the final release day.
Testing RC3 on a self-hosted Linux server
For a self-hosted WordPress site, the useful question is not only whether the editor opens. RC3 should be tested against the same web-server, PHP and database combination used in production. A staging copy running Nginx or Apache, PHP-FPM and MariaDB or MySQL can reveal compatibility problems that a clean test installation may miss.
Clone the site before changing WordPress Core
Create a separate staging hostname and copy both the database and wp-content directory. Keep the staging site blocked from public indexing, replace production credentials and disable outgoing transactional email. Do not perform release-candidate testing inside the live site’s document root.
Before updating, record the current environment:
wp core version
wp plugin list --status=active
wp theme list --status=active
php -v
mysql --versionThis short inventory makes a failed test easier to reproduce. It also tells a plugin developer exactly which PHP, database, theme and plugin versions were present when the problem appeared.
Watch PHP-FPM and web-server logs
After updating the staging copy, inspect the PHP-FPM error log and the Nginx or Apache error log while repeating normal admin and front-end actions. A page that looks correct can still trigger deprecated-function warnings, PHP notices or failed background requests.
Test scheduled posts, REST API requests, media uploads, cron events, forms and cache purges. If the site uses Redis or another persistent object cache, clear it after the Core update so the test does not reuse incompatible cached objects.
Prepare a real rollback
A rollback should restore both files and database state. Replacing WordPress Core files alone may not undo a database upgrade or plugin migration. Confirm that the staging backup can be restored before starting the test, and keep the production site on the current stable WordPress release.
How to test WordPress 7.1 RC3 safely
The safest method is to use a staging site, a local development environment or WordPress Playground. Do not update LinuxPanda or another business-critical production site to RC3.
- Create a new staging or local WordPress installation.
- Back up its database and files, and verify that the backup can be restored.
- Install and activate the official WordPress Beta Tester plugin.
- Select the Bleeding Edge channel and the Beta/RC Only stream.
- Update to the current WordPress 7.1 release candidate.
- Run normal publishing, plugin, theme and media workflows.
- Record exact reproduction steps if something fails.
- Check PHP-FPM, web-server and WordPress debug logs for hidden errors.
Experienced users can alternatively download the package from the official release archive. Bugs can be reported through WordPress Trac or the Alpha/Beta support forum after checking that the problem is reproducible and has not already been reported.
What happens before the 19 August release?
WordPress plans a release dry run and 24-hour code freeze on 18 August. If no blocking issue forces a delay, WordPress 7.1 is targeted for release the following day. The date remains a target until the project publishes its final release announcement.
Production-site owners do not need to install RC3. The practical step is to confirm backups, update staging copies, check critical plugin support and prepare a controlled upgrade plan for the stable release.
Frequently asked questions
Is WordPress 7.1 RC3 stable?
It is a late testing build, but it is still pre-release software and may contain bugs. Use it only in a test environment.
Can I install RC3 on my live website?
No. WordPress recommends testing release candidates on a staging server, local installation or disposable test site.
When will WordPress 7.1 be released?
The current target is 19 August 2026, following a dry run and 24-hour code freeze on 18 August.
Will every roadmap feature appear in WordPress 7.1?
Not necessarily. The roadmap describes planned work, while the final release notes will confirm what actually ships.
Comments