WordPress 7.1 RC1 Is Here: What Changed and What You Should Test

WordPress 7.1 entered the release-candidate phase on August 5, 2026, and was officially released on August 19, 2026.

RC1 marked the point where the release stopped feeling like a collection of experiments and started behaving like the version millions of sites would soon run.

WordPress 7.1 was officially released on August 19, 2026. Its release-candidate sequence included RC1 on August 5, a security-focused RC2 on August 6, RC3 on August 12, and RC4 plus the release dry run on August 17 before the final launch during WordCamp US.

At this stage, the question is no longer just “What new features are coming?”

It is:

Would your theme, plugins, media workflow, editor customizations, and business-critical site flows behave correctly when WordPress 7.1 reached production?

This historical RC1 guide explains the changes that deserved attention during testing and preserves a practical pre-release test plan.

First: What Does RC1 Actually Mean?

A WordPress release candidate is one of the final stages before general release. The feature set is expected to be close to final, while contributors focus heavily on bugs, regressions, compatibility problems, documentation, and release preparation.

Under the official WordPress 7.1 release schedule, RC1 was also the point where the project planned to publish the Field Guide and associated developer notes, commit the About page, begin the final release post, enter hard string freeze, and create the release branch.

That makes RC1 one of the most useful points in the cycle for plugin authors, theme developers, agencies, and technical site owners to test.

Beta testing helps shape the release. RC testing asks a more practical question:

Is what is about to ship compatible with the real WordPress ecosystem?

WordPress 7.1 Release Timeline

Date	Milestone	What happened
July 15	Beta 1	The main 7.1 feature set entered public testing.
July 17	Beta 2	An extra beta shipped alongside WordPress 7.0.2.
July 22	Beta 3	Testing continued with bug fixes and refinements.
July 29	Beta 4	The final scheduled beta preceded the RC phase.
August 5	RC1	The Field Guide, hard string freeze, release branch, and final compatibility testing began.
August 6	RC2	A silent security release candidate shipped.
August 12	RC3	The third release candidate continued final stabilization.
August 17	RC4 and dry run	The final release candidate was followed by the release dry run and extended code freeze.
August 19	WordPress 7.1	WordPress 7.1 was officially released during WordCamp US 2026.

The Biggest WordPress 7.1 Changes Worth Testing

1. Responsive styling moves deeper into the editor

One of the most visible 7.1 changes is responsive styling.

WordPress 7.1 allows block styling to change across screen sizes directly from the editor rather than forcing users to write custom CSS for every responsive adjustment. The Beta 1 announcement highlighted responsive controls for both Global Styles and individual blocks, while theme authors can define responsive breakpoints through theme.json.

This sounds like a design feature. It is also a compatibility feature.

What to test:

• Open pages and templates where your theme already uses responsive CSS.
• Change spacing, typography, dimensions, or other supported styles across breakpoints.
• Check desktop, tablet, and mobile previews.
• Confirm editor output matches the front end.
• Look for duplicate or conflicting rules from the theme and WordPress-generated styles.
• Test custom blocks whose styles depend on viewport-specific CSS.

If your plugin adds custom block controls, you should also test how those controls interact with the new responsive workflow rather than assuming a desktop-only setting model.

2. Interactive state styling reduces the need for custom CSS

WordPress 7.1 also expands styling around interactive states such as hover and focus.

That matters for buttons, navigation, links, cards, and interactive components where theme authors have historically written CSS outside the editor.

What to test:

• Button hover and focus states.
• Link styles inside content blocks.
• Keyboard focus visibility.
• Global Styles versus block-level overrides.
• Theme style variations.
• Custom blocks that already generate their own pseudo-state CSS.

Do not test only with a mouse. Focus states are an accessibility behavior as much as a design detail.

3. Notes becomes a much stronger collaboration system

WordPress 7.1 continues the collaboration work around Notes.

The Beta 1 release included richer text formatting, @mentions, multiple conversations on the same block, inline notes on text selections, and better handling of long notes.

This is particularly relevant for editorial teams, agencies, publishers, and clients who review content inside WordPress instead of moving feedback into Slack, email, or documents.

What to test:

• Add multiple Notes to the same block.
• Create a Note on selected text.
• Use @mentions with different user roles.
• Test links, formatting, emoji, and long-note collapse behavior.
• Resolve conversations and reload the editor.
• Test revisions or content updates after Notes have been added.

For sites with custom roles or permission plugins, pay extra attention to which users can see and interact with collaboration features.

4. Media processing is changing in a meaningful way

This is one of the areas we would test most aggressively.

WordPress 7.1 introduces client-side media processing in supported browsers. Instead of depending entirely on PHP plus GD or Imagick to generate image sizes and conversions, supported image processing can happen in the browser using WebAssembly before the generated files are uploaded to WordPress.

The official developer note says this covers operations such as compression, resizing, format conversion, rotation, and thumbnail generation. It also expands modern format support and is designed to reduce server-side image-processing load.

WordPress still falls back to the server-side path when the browser or runtime does not support the client-side pipeline.

What to test:

• Normal JPEG and PNG uploads.
• Very large photos.
• HEIC/HEIF images from iPhones.
• WebP and AVIF uploads.
• EXIF-rotated images.
• Animated GIFs.
• Custom image sizes registered by your theme or plugins.
• CDN, watermark, image compression, media offload, and metadata plugins.
• Uploads on both Chromium-based browsers and browsers that use the server fallback.

Beta 3 already fixed several media issues, including long animated GIF uploads hanging, EXIF rotation problems, and duplicate entries from single HEIC uploads in Safari. That is exactly why RC testing matters: complicated media workflows expose bugs that basic “upload one image” tests miss.

5. The Media Library now uses infinite scrolling by default

WordPress 7.1 enables infinite scrolling in the Media Library grid by default, with a user-level option to disable it.

For a small site, this may feel like a minor UX change.

For a publication, photography site, store, or media library with tens of thousands of attachments, it is worth testing carefully.

Check:

• Media-library performance with large attachment counts.
• Plugins that modify the Media Library grid.
• Filters and custom attachment taxonomies.
• Selection behavior inside the media modal.
• Lazy-loaded data or custom pagination logic.

6. The admin toolbar becomes persistent inside editors

WordPress 7.1 makes navigation more consistent by bringing the admin toolbar into the editing experience.

The official navigation Dev Note also changes the old behavior where the WordPress/site icon acted like a back button. The editor now uses a dedicated back control, while the toolbar and site icon have clearer roles.

This is a small visual change with potentially large plugin implications because many plugins add items, notices, buttons, or custom UI around the top editor area.

What to test:

• Plugin-added toolbar items.
• Editor header customizations.
• Full-screen and distraction-free modes.
• Back navigation from posts, templates, and Site Editor screens.
• Admin toolbar CSS that assumes it is not present inside the editor.

7. The command palette gets easier to scan

The command palette is becoming more organized, including grouped sections such as recent commands, matching results, and suggestions.

Plugins that register commands should check:

• Whether commands appear in the expected section.
• Command labels and discoverability.
• Keyboard workflow using Ctrl/Cmd + K.
• Duplicate command names.
• Context-sensitive commands inside the editor versus admin screens.

8. New and improved blocks need theme-level testing

The Beta 1 announcement highlighted several block changes, including a new Playlist block and Tabs block, plus improvements to HTML content, backgrounds, images, and shortcode handling.

WordPress 7.1 also adds support that allows background gradients to work alongside background images for several core blocks rather than one silently replacing the other.

Test these inside your theme:

• Tabs across desktop and mobile.
• Keyboard navigation and focus in interactive blocks.
• Playlist styling and audio behavior.
• Background image + gradient combinations.
• Image blocks marked as decorative.
• Custom HTML workflows with nested editable blocks.
• Spacing and typography inherited from Global Styles.

The most useful test is not whether the block inserts. It is whether the block looks correct inside the theme you actually ship.

9. Developers should check editor-component changes

WordPress 7.1 includes several changes in @wordpress/components.

Form controls now use a 40px default height without needing the previous opt-in prop, and deprecated APIs such as the old Navigation component and __experimentalApplyValueToSides utility are removed.

If your plugin builds custom editor UI, this is worth a focused regression test.

Check for:

• Unexpected control heights.
• Broken layouts where fixed heights were assumed.
• Removed/deprecated component imports.
• Custom Emotion styling and override ordering.
• Console warnings and JavaScript errors.

10. The iframed editor deserves plugin and theme attention

The WordPress editor has been moving toward a more consistently iframed canvas. WordPress 7.1 continues that direction, which helps isolate editor content from admin styles but can expose extensions that assume editor content lives in the same document context as the surrounding admin UI.

Test:

• Custom blocks.
• Editor-only CSS.
• JavaScript that queries editor DOM directly.
• Meta boxes and sidebars interacting with canvas content.
• Page builder or custom workflow integrations.

For block developers, modern Block API versions and supported editor APIs are much safer than direct DOM assumptions.

What Changed Between Beta 1 and the RC Stretch?

RC1 is not just Beta 1 with a new label.

By Beta 3, WordPress reported more than 71 issues addressed since Beta 1 across Core and Gutenberg work.

Beta 3 also changed how the “Apply globally” styling workflow behaves. Rather than treating all local style changes as one all-or-nothing global update, the interface adds a review step so users can choose which changed styles should become global.

Media fixes also continued, as did work around Notes, responsive styling, and custom CSS.

One particularly useful reminder: not everything proposed for a release makes the final cut. Unicode email address support, which was being explored earlier in the cycle, was explicitly moved out of WordPress 7.1 during Beta 3 so the work could continue with broader testing.

That is why an article written from an early roadmap can become inaccurate quickly. RC1 and the Field Guide became the better checkpoint for what was actually approaching release.

What Site Owners Should Test

You do not need to be a developer to help test WordPress 7.1.

Take a staging copy of a real website and perform the jobs that matter to that site.

Publishing workflow

• Create a post.
• Add images.
• Use the block types your editors normally use.
• Save drafts.
• Preview.
• Schedule or publish.
• Edit an existing post.
• Check revisions.

Navigation and layout

• Edit menus or navigation.
• Open the Site Editor.
• Change a template.
• Test desktop and mobile.
• Check reusable patterns and synced content.

Forms and email

• Submit every important form.
• Confirm database entries.
• Confirm notifications arrive.
• Test autoresponders and CRM integrations.

Commerce or membership

• Browse products.
• Add to cart.
• Checkout with a test payment method.
• Open account pages.
• Test restricted content.
• Trigger transactional email.

Media

• Upload real files your team uses.
• Test image editing.
• Build galleries.
• Check image optimization/CDN behavior.

RC testing is strongest when it imitates actual work.

What Plugin Developers Should Test

Plugin authors should concentrate on integration surfaces.

• Editor compatibility: custom blocks, inspector panels, sidebars, commands, toolbar additions.
• Media hooks: custom sizes, metadata, offload, compression, watermarking, remote imports.
• Admin UI: component sizing and shared design-system changes.
• REST/API behavior: custom endpoints and media integrations.
• JavaScript: deprecated component usage and direct DOM assumptions.
• Permissions: collaboration, Notes, custom roles, and editorial workflows.
• Performance: unexpected queries, HTTP calls, warnings, or background jobs.

Run the test suite against RC1 where possible, but do not stop there. Automated tests rarely simulate the full editing experience.

What Theme Developers Should Test

WordPress 7.1 is especially relevant to block themes.

• Global Styles.
• theme.json configuration.
• Responsive controls and breakpoints.
• Hover/focus styling.
• New core blocks.
• Background gradients plus images.
• Editor/front-end visual parity.
• Template editing.
• Admin color scheme interactions where relevant.

Also check classic themes that add editor styles or custom block CSS. A change does not need to be “for block themes only” to reveal a styling assumption.

How to Test WordPress 7.1 RC1 Safely

The most important rule:

Do not install a release candidate on a production or mission-critical site.

WordPress’s own Beta announcements explicitly recommend testing development releases on a test environment or local site.

Option 1: WordPress Playground

For quickly exploring the editor and new features, Playground is the lowest-friction option because it runs WordPress in the browser without a traditional hosting setup.

Use it to explore interface changes. Use a staging clone for real plugin/theme compatibility.

Option 2: staging environment

This is our preferred workflow for a business site.

• Create a fresh staging clone.
• Confirm staging has the same plugins, theme, PHP version, and important configuration as production.
• Take a baseline screenshot/performance/error-log snapshot.
• Install RC1 using the supported testing method.
• Run a documented test checklist.
• Compare errors and behavior against the baseline.

Option 3: local development

Plugin and theme developers should also test against a local development environment where debugging tools, logs, automated tests, and version control are available.

The WPTopper WordPress 7.1 RC1 Test Checklist

Area	Test	Pass?
Login	Login, logout, password reset, role permissions	□
Editor	Create/edit posts, save, preview, revisions	□
Styles	Responsive controls, hover/focus, Global Styles	□
Media	JPEG, PNG, HEIC, WebP/AVIF, GIF, cropping	□
Theme	Templates, headers, footers, mobile layout	□
Forms	Submission, validation, notifications, integrations	□
Email	Password, form, order, system emails	□
Commerce	Cart, checkout, payment sandbox, account	□
Plugins	Settings, admin pages, editor extensions	□
Performance	Front end, editor, admin, database/error logs	□
Accessibility	Keyboard navigation, focus, decorative images	□
Integrations	CRM, API, webhooks, CDN, external services	□

Found a Problem? Make the Report Useful

“My site broke” is frustrating. It is not a reproducible bug report.

Record:

• WordPress version and RC build.
• PHP version.
• Theme and version.
• Relevant plugin versions.
• Browser and operating system.
• Exact steps to reproduce.
• Expected result.
• Actual result.
• Console or PHP errors.
• Whether the issue exists on the previous stable WordPress release.

If a problem disappears when a specific plugin is disabled, test again before concluding that WordPress Core is responsible. Compatibility issues can live in Core, plugins, themes, or the interaction between them.

Should Normal Site Owners Install WordPress 7.1 RC1?

On production? No.

On a staging site, yes. During the RC window, that helped catch problems before release. For WordPress 7.1 today, stage the final update and verify critical workflows before production.

For agencies and product companies, this is exactly the right time to test. Waiting until the final release means your customers become the compatibility test.

What Happened After RC1?

The release continued through the following milestones:

• RC2 — August 6
• RC3 — August 12
• RC4 and the release dry run — August 17
• WordPress 7.1 final release — August 19

WordPress 7.1 has now shipped. This article remains a record of the RC1 testing priorities; site owners should still validate the final release on staging before updating production.

Frequently Asked Questions

When was WordPress 7.1 RC1 released?

WordPress 7.1 RC1 was released on August 5, 2026.

When was WordPress 7.1 released?

WordPress 7.1 was officially released on August 19, 2026, during WordCamp US.

Is WordPress 7.1 RC1 safe for production?

No. Release candidates are for testing and development. Use staging, local development, or WordPress Playground rather than a production or mission-critical site.

What is the biggest WordPress 7.1 change?

There is no single answer. For site builders, responsive and interactive state styling are major changes. For publishers, Notes and media improvements matter. For developers and hosts, client-side media processing and editor/API changes deserve close testing.

Did every feature from the WordPress 7.1 roadmap ship?

No. The roadmap was provisional, and Beta 3 confirmed that Unicode email support moved out of 7.1. The shipped release should be treated as the source of truth.

How should plugin developers test RC1?

Run automated tests where available, then test real admin/editor workflows, media handling, custom blocks, REST integrations, permissions, and JavaScript compatibility on a staging or development environment.

Where can I report a WordPress 7.1 bug?

WordPress directs testers to the Alpha/Beta support area for issues and WordPress Trac for reproducible Core bug reports. Contributors can also follow testing work through Make WordPress channels.

Final Take

WordPress 7.1 is not a release we would test by clicking around the dashboard for five minutes.

The editor is changing. Styling is changing. Media processing is changing. Navigation is changing. Block capabilities are expanding. Developer APIs and shared components continue to evolve.

None of that automatically means your site will break.

During RC1, it meant testers had a chance to find problems before the final release reached production.

That testing lesson still applies: clone a real site, test real workflows, document failures, and make production update day boring.

Continue with our guide to test WordPress updates safely, or review essential WordPress plugins for a new site.