WordPress 7.1 — the second major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality. of 2026 — is coming fast. The official release will launch August 19, 2026.

With 7.1 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 slated for release on the July 15th, your help testing is vital to ensuring a stable and reliable release that continues to benefit WordPress users across the globe.

Early testing is critical.

Early testing helps identify bugs, usability issues, and compatibility concerns while there’s still time to address them. 

Then at launch, you’ll find your testing might have led to an improvement you can see and feel.

Got a few minutes? A few hours? Every bit of testing makes a big difference — possibly, the difference between a new feature landing in 7.1 or not.

Stay informed!

The WordPress 7.1 release schedule page has everything you need to know about the latest pre-release builds and milestones.

For real-time updates, you can follow discussions and find collaboration opportunities in the #core-test and #core channels in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. You might want to join both channels! 

Also, you are more than welcome at every upcoming release party, testing session, and test scrub throughout the release cycle and beyond.

Thank you!

Did you know you’re already a hero? Anything you do — even just reading this post — helps shape WordPress 7.1 into the strongest, most polished release ever. 

And with the new features coming in 7.1, you’ll help make it a blockbuster release for the entire community.

🧪 Testing Tips

You don’t need to be a certified software tester or QA professional, or any kind of expert, to help test WordPress. 

Simply using WordPress as you would every day (on a test installation, of course!) can help identify any bottlenecks and bugs that a WordPress user may encounter. through processes that mimic your daily projects, workflows, and experiments and report any findings. 

Or if you feel compelled, push WordPress to its limits. Try to break things. Have five editors in wp-admin at once, have someone relentlessly reload the home page, step outside standard practices and use WordPress in unexpected ways.

Notice something unexpected? Run into a bug? Is a feature not behaving the way you thought it would? Please consider reporting it to the Alpha/Beta area of the support forums, or directly to WordPress Trac if you are comfortable writing a reproducible bug report.

Not sure what the expected behavior should be? No problem! Join the conversation in the #core-test channel on the Making WordPress Slack, where contributors and developers are always happy to help. New tester? You have the global WordPress community at your service. Everyone in it is happy to welcome and support you. 🌍 You’re also welcome and encouraged to join the #core-test Slack channel and ask questions about testing!

Again — every report, question, or observation you submit makes a difference, and helps improve WordPress for hundreds of millions of users. Testing is a valuable way to contribute to the WordPress project, and testers are included in release credits on the final release. 

Recommendations for Testing WordPress Beta/RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. Versions:

• Test the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Features that Matter to You:  Use your site the way you usually do. For instance, if you’re a blogger, running a social platform, or managing an e-commerce store, run your tests through those specific scenarios.
• Set up a staging site (ask your hosting provider if this is new to you). Do not test or update your live site with a beta version for testing; your users might see any issues that come up.
• Update WordPress in the staging environmentStaging Environment A staging environment is a non-production copy of your site. This is a private place to build the site -- design, copy, and code -- until your client approves it for production or live. Sometimes used in addition to, or as a Development Environment.. Keep using your site as normal. 
• Take note of anything you experience after the update. Log any errors, alerts or strange behavior during your testing process, and the steps you took when you encountered the issue. 
• Use the General Checklist below to verify everything works as you’d expect.

How to test WordPress Beta Versions 

You can test WordPress Beta versions in several ways. Some are fast and easy; some let you run sophisticated tests on the latest backend features.

All of them keep your live websites safe from the effects of any issues you find:

WP-Playground

Playground is a fast and easy way to spin up a test site — without setting up a full environment. Get started testing right away on WordPress Playground.

A Local Site on your computer

Software like Local or wp-env lets you build a full WordPress site on your computer — no internet required.

How to set up your site:

1. Download and install Local.
2. Create a new WordPress site.
3. Once your site is up and running, install and activate the WordPress Beta Tester pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.. This plugin lets you install pre-release versions of WordPress.
4. Navigate to Tools → Beta Testing.
5. Choose one of the following options:
   • Bleeding Edge → Beta/RC Only to test the latest Beta or Release CandidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge..
   • Bleeding Edge → Nightlies (or Point ReleaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. Nightlies, if applicable) to test the latest development build with the newest code changes.
6. Click Save Changes.
7. Go to Dashboard → Updates.
8. Confirm that an update is available (for example, Update to WordPress 7.1 Beta, Release Candidate, or Nightly, depending on the option you selected).
9. Click Update to WordPress 7.1 Beta/RC/Nightly and wait for the update to complete.
10. Verify that your site is now running the selected pre-release version of WordPress.

Follow this guide for more detailed instructions.

WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/

Are you most at home in the command line? WP-CLI lets you install a WordPress beta version in record time.

Steps:

• Create a local WordPress site however you like to do it. Wait for the notification that your site is ready.
• Open your terminal and navigate to the root directory of your WordPress installation.

Run the following command to update to the latest beta version:

wp core update --version=7.1-beta1

Or

wp core update --version=7.1-RC1

(Replace the version number as needed, such as --version=7.1-beta2.)

With WP-CLI, you can install several different versions and switch between them easily. That makes it much easier to test specific builds and compare them.

A Staging Site on your host

You can build a staging site for your production/live site and test it with the WordPress beta/RC version — without affecting your live site.

That way, you’ll be sure everything works the way it should — long before WordPress 7.1 lands in your production/live environment.

Testing Patches

A patch is a quick and smaller update that fixes security or other bugs. Maybe you don’t need to test an entire version of WordPress, but you do want to test one or more patches to see if a bug is fixed.

In that case, you’ll need a specific local WordPress development environment.

Follow these instructions to set it up.

Testing tickets in the browser 

Do you have a particular PR in the wordpress-develop or gutenberg repo that you’d like to test in the browser? 

You can use Playground for that, and test any core tickets you like — without installing any software on your system. Just use these links:

• https://playground.wordpress.net/wordpress.html 
• https://playground.wordpress.net/gutenberg.html 

General Testing Checklist

Want to see how well your site runs on the very latest version of WordPress? Here’s a checklist that should give you an idea — and won’t take all day.

Use one of the methods above to set up your testing site, and update to the latest Beta/RC version. 

Enable debugging in wp-config.php, and update your theme and plugins.

• Did any plugins or themes deactivate automatically after the update?
• Check the WordPress Site Health tool. Did you find any new warnings or issues?
• Check templates and patterns, and then actual posts and pages, for layout problems. Are all the elements lined up properly? Is spacing correct?
• Test links and permalinks to ensure there are no 404 or other errors.
• Do design elements, images, and media look the way they should? Do media files load and play properly? How does the audio sound?
• How are the sitemap and robots.txt files working?
• Can users at every permission level get to the admin dashboard without errors? Does each level show the right tools, and do they work?
• Does your site have custom blocks? Add content to a new blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.. Edit it. Now edit a block that already has content.
• Create a new post:
  • Add content.
  • Copy some text and paste it.
  • Add a few different kinds of media files. 
  • Save the post and watch the console for any issues.
• Create a new page.
  • Add content. 
  • Open it in several different browsers. Does it look and feel right in each? Does the page function properly in each?
• Open the browser’s developer tools. Check each tab, plus the console, for errors, warnings, or notices. Check any visible CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. or JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com for unexpected changes.
• Check the error log file for notices, warnings, and errors — especially fatal errors.
• Have you set up scheduled posts or automated tasks (like backups)? Can you find them in the admin? Do they run on schedule? Do they work?
• Check integrated services like payment gateways or analytics. Do they still connect? Do they execute? 
• Open your site in different browsers and make sure all functionalities work as expected — beyond the ones you checked on pages earlier.
• Check site performance: page loading, APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. calls, database requests. You might want to check this on a few devices in real life. 
• Also, every browser has tools that let you simulate a variety of network conditions. How does your updated site handle low bandwidth?
• Test accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) basics: keyboard navigation, contrast,  screen-reader behavior — whatever assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology you have on hand.
• Check your forms — contact forms, checkout forms, login forms, and more. Can you fill all the fields? Submit and clear? Does the data end up in the right place?
• Can you upload media? Edit images? Does gallery functionality work properly?
• Check your theme. Does the basic theme look right? Did theme customizations — in the Site Editor, or the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. in Classic themes — change in the upgrade? Or did they sail through perfectly?

Key Features to Test

Collaboration

New Notes features

Notes let people leave feedback directly in the editor. WordPress 7.1 makes them much richer: notes on specific words or across multiple blocks, rich text inside notes, @mentions, multiple note threads on the same block, a show more/less toggle for long notes, and a toolbar button that puts starting a note within easy reach.  

Testing Steps

1. Create a new post and add a few paragraphs of content.
2. Select some text inside a paragraph.
3. Open the block toolbar (or the ⋮ options menu) and choose Add note (look for a note/comment icon).
4. Type a note and save it. Confirm the note appears anchored to the text you selected.
5. Reply to your own note and confirm the reply shows in the thread.
6. Add formatting using keyboard shortcuts — there’s no visible toolbar. Select text and press ⌘/Ctrl + B (bold), ⌘/Ctrl + I (italic), or ⌘/Ctrl + K (link). To get code formatting, type text wrapped in backticks (`like this`). Confirm the formatting is kept after saving. (Formatting is intentionally limited to bold, italic, link, and code.)
7. Start a second, separate thread on the same block and confirm both threads are tracked independently.
8. Add a note that spans more than one block and confirm it’s tracked correctly.
9. Add a long note and confirm the show more/less toggle collapses and expands it.
10. @mention another user in a note and confirm the mention is inserted correctly.

Expected:

Notes attach to the right content; replies, mentions with notifications, multiple threads per block, keyboard formatting, and the show more/less toggle all work as described.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow #76316 for more details.

Design & Interface

Responsive styling

Style a block differently for tablet and mobile directly in the editor — without custom CSS. Turn on Responsive editing from the device-preview dropdown, switch to Tablet or Mobile, and the change is saved only for that breakpoint.

📣 Dedicated Call for Testing post: Call for Testing: Responsive Styling — follow it for the full set of scenarios (resize handles + device view syncing, per-viewport styles, the viewport badge, hidden-on-device blocks, front-end checks, and notes for plugin/theme developers).

If you encounter any issues or unexpected behaviour while testing, please log them here. Reference PR #75121 for more details.

Interactive states styling

You can now style a Button’s interactive states — hover, focus, and active — without writing a single line of CSS. For example, a button that changes color the moment you hover over it.

There are two layers to this:

• Global Styles: set hover, focus, and active styles once and they apply to every Button across the whole site.  
• Individual block instance: A single Button can have its own hover, focus, and active styles that leave every other button untouched. Note that per-instance pseudo states are currently supported by the Button block only; other blocks don’t expose them yet.

Testing Steps

Global Styles first (applies to all buttons)

1. Open the Site Editor and go to Styles → Blocks → Button.  
2. Use the States selector to switch to the Hover state.  
3. With Hover active, set a different Background and Text color (and any other styles you like).  
4. Repeat for the Focus and Active states, giving each its own look.  
5. Save the styles.  
6. On the frontend, hover, focus, and click a button and confirm the correct styles appear for every button on the site.

Then an individual Button instance (applies to one button only)

1. Add two or more Button blocks to a post or page.  
2. Select one of them and open its Styles settings.  
3. Open the state selector in the block card headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. (a small three-dot menu) and switch to Hover.  
4. Change a style for example the Background color. The canvas should update immediately; toggle Show state on canvas off and on to confirm it’s previewing the hover look live.  
5. Save and view the post on the frontend. Hovering that one button should use the styles you set, while the other buttons stay unchanged.  
6. Switch to Focus and Active and repeat, giving that single button its own states.  
7. Reset the hover styles for that instance and confirm the other states and the global styles are unaffected.

Expected:

Global hover, focus, and active styles apply to all buttons site-wide, while per-instance styles apply to only the selected button. The two layers combine sensibly, resetting one layer doesn’t disturb the others, and Show state on canvas previews the state in the editor without you having to actually hover.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow issue #38277 (per-instance support landed in PR #76491) for more details.

Persistent Toolbar

The admin toolbar now appears inside the Post Editor and the Site Editor too — previously it disappeared in the Site Editor — along with a few visual refreshes: the home icon becomes your site icon (when set), your profile avatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. is circular, and the command palette icon is removed from the editor toolbar.

Testing Steps

1. Set a Site Icon (Site Editor → Design → Identity, or Settings) if you haven’t already.
2. Open the Post Editor (edit any post) and confirm the admin bar is visible at the top.
3. Open the Site Editor (Appearance → Editor) and confirm the admin bar is visible there too (it used to disappear).
4. Confirm the admin bar’s home item shows your site icon, not the old dashicon (with no site icon set, it falls back to the default icon).
5. Confirm your profile avatar is a circle, not a square.
6. Confirm there is no command palette icon in the editor toolbar anymore, and that the palette still opens with Cmd/Ctrl + K.
7. Switch your Admin Color Scheme (Users → Profile) and confirm the admin bar in both editors follows the scheme.
8. Resize to a narrow / mobile width and confirm the admin bar still looks correct in the editors.

Expected:

The admin bar is visible in both the Post and Site Editor, shows the site icon (when set) and a circular avatar, no longer carries the command-palette icon in the editor toolbar, and follows the chosen admin color scheme.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow issue #79036 for more details.

Dedicated Identity section

The Design → Identity panel now lets you edit your Site Title and Site Tagline right alongside the existing Site Logo and Site Icon no need to jump over to Settings. Changes update the matching Site Title and Site Tagline blocks live in the editor preview.

Testing Steps

1. Open the WordPress Dashboard and go to Appearance → Editor.
2. In the Site Editor, go to Design → Identity.  
3. Confirm four fields appear in order: Site Title, Site Tagline, Site Logo, Site Icon.  
4. Confirm the description text below each field is the same size and style.  
5. Edit the Site Title and watch the Site Title block update in the preview.  
6. Edit the Site Tagline and watch the Site Tagline block update in the preview.  
7. Click Save and confirm all edited fields appear in the save panel.  
8. Reload the editor and confirm your changes persisted.

Expected:

Site Title and Site Tagline can be edited from the Identity panel, the preview updates as you type, and changes save and persist correctly.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow #76261 for more details.

Admin color scheme reflected in the Site Editor

The Site Editor now follows your chosen WordPress admin color scheme instead of always showing a fixed dark interface. The sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. and surrounding chrome pick up your scheme’s colours, while the editing canvas stays white for readability.

Testing Steps

1. Go to Users → Profile and pick an Admin Color Scheme (e.g. Modern, Blue, Coffee, Ectoplasm, Midnight, Ocean, Sunrise).
2. Open the Site Editor (Appearance → Editor).
3. Confirm the sidebar and interface chrome reflect the chosen colour scheme, not a fixed dark background.
4. Confirm the editing canvas / content area stays white and readable.
5. Switch to a different admin colour scheme and confirm the Site Editor updates to match.
6. Resize the browser to a narrow / mobile width and confirm the themed sidebar and white content still look correct.

Expected:

The Site Editor chrome matches your admin colour scheme across all schemes and at mobile widths, while the content canvas stays white.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow #78397 for more details.

Command palette sections and Recently used

The command palette (Cmd/Ctrl + K) is easier to navigate: commands are now grouped into sections: Suggestions, Recent, and Results. The commands you use are remembered under Recent, saved to your user preferences. The palette is also a bit wider for easier scanning.

Testing Steps

1. In the editor, press Cmd/Ctrl + K to open the command palette.
2. Run a few different commands and close the palette.
3. Reopen it and confirm a Recently used section shows the commands you just ran.
4. Start typing and confirm results are grouped into recent, suggested, and matching sections.
5. Reload the page (or start a new session) and confirm recently used commands persist.
6. Check the layout is readable and easy to scan.

Expected:

Commands are grouped into clear sections, recently used commands persist under Recent and the palette is easier to scan.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow #75616 for more details.

Choose which block styles to apply globally

The block inspector’s Apply globally action used to be all-or-nothing: one click pushed every style you’d changed on the block into Global Styles, with no way to see what was about to change or to leave part of it behind.

WordPress 7.1 adds a review step. Apply globally now opens a modal that lists each changed style on its own row, showing the current value next to the new value, with a checkbox for each. Every row is selected by default, so you can deselect the ones you don’t want and apply only the styles you meant to. Anything you deselect stays as a local override on the block and isn’t pushed or cleared.

Testing Steps

1. Add a Paragraph block to a post and select it.
2. In the block inspector (right sidebar), change a few different styles on the block — for example make the text uppercase, set a text colour, add some padding, and set a border colour.
3. Open the Advanced panel in the block inspector and click Apply globally.
4. Confirm a modal opens (it no longer applies everything immediately), and that it lists one row per changed style, each showing the current value → the new value, with all rows checked by default.
5. Deselect one row, then click Apply.
6. Confirm only the checked styles were pushed to Global Styles, and that a snackbar appears. Click Undo in the snackbar and confirm the previous state is restored.
7. Confirm the style you deselected is still set on the block as a local override — it should not have been pushed, and it should not have been cleared either.
8. Open Apply globally again and confirm the modal now lists only the style you didn’t push.
9. Deselect every row and confirm the Apply button is disabled.
10. Reopen the modal and dismiss it with Cancel, the close (×) button, and the Escape key. Each time, confirm nothing changes on the block or in Global Styles.
11. On a block with no changed styles, confirm the Apply globally button is disabled.
12. Resize the browser to a narrow / mobile width and confirm the modal still displays correctly.

Expected:

Apply globally opens a review modal listing each changed style with its current and new values, all selected by default. Only the selected styles are pushed to Global Styles; deselected styles remain as local overrides on the block and are neither pushed nor cleared. Apply is disabled with nothing selected and when there are no changes to push, cancelling changes nothing, and Undo restores the previous state. 

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow PR #79839 for more details.

Media

Client-side media processing

When you upload an image in the editor, your browser now decodes, resizes, and encodes all sub-sizes locally (via wasm-vips) before sending them to the server — with support for AVIF, WebP, HEIC, UltraHDR, JPEG XL, and GIF→video conversion. Browsers and devices that can’t handle it silently fall back to the existing server-side path. (Chromium browsers only; requires more than 2 GB RAM and a decent connection.)

📣 Dedicated Call for Testing post: Call for Testing: client-side media processing — follow it for the full set of scenarios (baseline uploads, HEIC from iPhone, modern output formats, Ultra HDR, JPEG XL, GIF→video, batch/concurrent uploads, resilience, fallback paths, extensibility, and low-powered devices).

If you encounter any issues or unexpected behaviour while testing, please log them here (tag them `[Feature] Client Side Media`). Follow #76756 for more details.

Media Editor Modal

A new Media Editor Modal replaces the old inline image cropper, bringing cropping, rotation, flip, zoom, and metadata editing together in one streamlined place. It opens from the Crop button on the Image block (and the Site Logo and Cover blocks). 

📣 Dedicated Call for Testing post: Media Editor Modal: call for testing —follow it for the full set of flows (basic crop, details/metadata editing, preserving custom block alt/caption values, keyboard, and touch gestures).

Testing Steps

1. In a post or page, add an Image block and upload or choose an image.
2. Click the Crop button in the block toolbar and confirm a modal opens (instead of the old inline cropper).
3. Try a freeform crop — drag the handles — and confirm it works.
4. Try an aspect-ratio crop (a locked ratio) and confirm the crop constrains to that ratio.
5. Use Rotate (and fine rotation / snap, where shown) and confirm the image rotates.
6. Use Flip and confirm the image flips.
7. Use the Zoom controls (+ / −) and confirm the image zooms within the crop frame.
8. Toggle the crop handles on/off, if available, and confirm they behave.
9. Edit the metadata (for example, alt text or caption) in the modal, then Save.
10. Confirm the cropped/edited image is applied to the block and persists after saving the post and reloading.
11. Repeat from the Site Logo and Cover block crop buttons to confirm the modal opens there too.

Expected:

The Media Editor Modal opens from the Crop button, supports freeform and aspect-ratio cropping, rotation, flip, zoom, and metadata editing, saves the result back to the image, and is reachable from the Image, Site Logo, and Cover blocks.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow #73771 for more details.

Smarter galleries

Gallery blocks get smarter: a new Dynamic Gallery mode automatically displays all the media attached to the current post — in the editor and on the frontend — much like the classic gallery shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. did. You can also manage a post’s attached images from a new Attachments categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. in the media inserter.

Testing Steps

1. Create a post and upload a few images to it, so they become “attached” to the post.
2. Add a Gallery block and, in its empty/placeholder state, choose the Use attached images option (Dynamic Gallery).
3. Confirm the gallery automatically shows all the images attached to the post.
4. Save and confirm the same images appear on the frontend.
5. Open the block’s Source settings, change the sort order, and confirm the images re-order accordingly.
6. Convert the Dynamic Gallery to a static gallery and confirm you can now add, remove, or reorder individual images.
7. Open the media inserter (the Media tab in the inserter) and find the new Attachments category.
8. Confirm it lists the images attached to the current post.
9. Use Attach to add an image and Detach to remove one, and confirm the Dynamic Gallery updates to match.

Expected:

A Dynamic Gallery auto-displays all media attached to the post (editor and frontend), respects the sort setting, and can be converted to a static gallery. The media inserter’s Attachments category lists the post’s images and lets you attach/detach, which the Dynamic Gallery then reflects.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow issue #77117 for more details.

Dashboard

Visual RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. improvements

The Visual Revisions view (from 7.0) lets you compare and restore past revisions visually, right in the editor. WordPress 7.1 polishes how autosaves fit into it. The autosave notice’s “View the autosave” now opens the visual revisions view (autosave selected, changes highlighted) instead of the classic screen, and restoring the autosave dismisses the notice — it falls back to the classic screen when visual revisions are off (e.g. classic metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes). The revisions timeline also shows an “Autosave” badge on autosave rows — visually and for screen readers — so they’re easy to tell apart from regular revisions.

Testing Steps

1. Edit a published post, change some content, and trigger a server autosave (wait for it, or run wp.data.dispatch( ‘core/editor’ ).autosave() in the console). Reload without saving.
2. On the autosave notice, click “View the autosave” and confirm the visual revisions view opens with the autosave selected and its changes highlighted (no page reload).
3. Click Restore and confirm the autosave content is applied and the notice disappears.
4. On a post with visual revisions disabled (e.g. classic meta boxes), confirm “View the autosave” falls back to the classic revisions screen.
5. Open a post with both revisions and a recent autosave, open the revisions screen, and confirm the autosave row shows an “Autosave” badge (regular rows don’t), announced to screen readers too.

Expected: 

“View the autosave” opens the visual revisions view (falling back to the classic screen when visual revisions are off) and restoring dismisses the notice; autosave rows in the timeline are clearly labelled “Autosave” while regular revisions aren’t.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow #79120 (PR #79947, PR #79950) for more details.

Untitled posts show an excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. in the Posts list

Posts and pages with no title used to show only “(no title)” in the list table, making untitled items hard to tell apart. In Compact view, WordPress 7.1 now appends up to 15 words of the post’s trimmed excerpt after “(no title)” — so untitled posts are identifiable at a glance.

Testing Steps

1. Create a few posts with no title and different opening content (plain text, blocks, an image). Go to Posts → All Posts in Compact view.
2. Confirm each untitled row shows “(no title)” followed by the first part of its content (up to 15 words, ending in an ellipsis), in a lighter weight than a normal title. A post whose content starts with only an image should show just “(no title)”.
3. Add a post with a title and confirm no excerpt is appended — the feature only applies to untitled posts.
4. Switch to Extended view and confirm the trimmed excerpt is not appended (the full excerpt already shows on its own line there). Switch back to Compact and confirm it returns.
5. Create an untitled password-protected post and confirm it shows only “(no title)” — no excerpt.
6. Repeat on Pages; trashTrash Trash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days. an untitled post and confirm the excerpt still shows next to “(no title)” (the title isn’t linked in Trash, as expected).
7. Confirm the list still sorts, searches, and paginates correctly, and that Quick Edit / Bulk Edit still work for untitled posts.

Expected: In Compact view, untitled posts and pages show “(no title)” plus a trimmed excerpt; titled and password-protected posts don’t; Extended view, Trash, sorting, and Quick/Bulk Edit all still behave correctly.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow Trac #65022 (PR #11553) for more details.

Re-parent a comment from the Edit Comment screen

The Edit Comment screen now lets you change which comment a reply is “In reply to” or set it to None to make it a top-level comment using a new dropdown in the Save box. Previously this couldn’t be done from the admin at all.

Testing Steps

1. On a post with threaded comments, go to wp-admin → Comments and click Edit on a reply.
2. In the Save box, click Edit next to “In reply to:” and pick a different comment from the dropdown (the comment itself and its own replies are left out, so you can’t create a loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop).
3. Click OK, then Update.
4. View the post on the frontend and confirm the comment is now nested under the new parent.
5. Edit it again, set “In reply to:” to None, Update, and confirm it appears as a top-level comment.

Expected: You can change a comment’s parent (or clear it to top-level) from the Edit Comment screen, and the new threading shows on the frontend.

Testing Instructions: 

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow Trac #65570 (PR #12406) for more details.

Blocks

Playlist block

The Playlist block plays back a list of audio tracks with an interactive waveform player and a track list. Add your audio files and play them right in the editor and on the frontend, and customise the waveform and track list from the block settings. It’s made up of Playlist → Playlist track (one per track).

Testing Steps

1. Add a Playlist block and upload a few audio files (e.g. MP3s). Confirm a track is added for each file, with a waveform player and a track list.
2. Press play and confirm audio plays; click another track in the list and confirm it switches. Save and view on the frontend, and confirm playback works there too.
3. In the block settings, open the Waveform panel and switch the Visualization style (Bars, Mirror, Line, Blocks, Dots, Seekbar). Confirm the waveform updates in the editor and on the frontend.
4. Set a waveform color and a waveform background color (try the gradient options too) and confirm they render in both the editor and the frontend.
5. Toggle the track-list options — Show tracklist, Show images (album-art thumbnails), Show artists, Show numbers, and Show track length — and confirm each shows or hides correctly.
6. Turn on Show play button artwork and confirm the track’s artwork appears inside the play button.
7. Change the font size in the typography settings and confirm it applies to the track list and the current track.
8. Set a background color, padding/margin, and border on the block and confirm they apply in the editor and on the frontend.

Expected: 

Audio plays back in the editor and on the frontend; the waveform’s visualization style, colors, and background render correctly; the track-list toggles (tracklist, images, artists, numbers, track length) and play-button artwork all work; and the block’s color, spacing, border, and typography styling apply consistently across editor and frontend.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow the PR #80203 and the iteration issue #77421 for more details.

Tabs block

The Tabs block shows a row of clickable tab labels above a set of content panels — click a tab to bring its panel into view. It’s made up of Tabs → Tab List (the tab buttons) and Tab Panels → Tab Panel (one panel per tab). The labels and panels stay automatically synchronised, so adding, removing, or reordering a tab updates its matching panel too.

Testing Steps

1. Add a Tabs block and confirm it inserts a tab list with two tabs and two matching panels. Then add, remove, and reorder a tab and confirm the corresponding panel syncs each time.
2. Style the Tab List globally under Styles → Blocks and confirm the styles apply to the tab button elements (the block gap is the exception). Override the styles on a single instance and confirm only that one changes.
3. Change the background color and confirm the tab buttons stay legible — their text and borders inherit the current text color.
4. Inspect the markup: confirm tabs and panels are linked by generated IDs, and that a manually-set panel ID is respected.
5. Save and view on the frontend; confirm clicking a tab switches the visible panel.
6. On the frontend, use Tab to focus the tabs and panels, Left / Right arrows to move between tabs, and Enter to activate one. With a screen reader, confirm the tab list’s aria-label (default “Tabbed content”) is announced.

Expected:
Tabs and panels stay synchronised, global Tab List styles apply to the tab buttons (overridable per instance, block gap excepted), tabs and panels are linked by correct IDs (custom IDs respected), and the block follows the W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/. tabs pattern — focusable with Tab, navigable with arrows, activated with Enter, and announced by screen readers.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow PR #80163 and the tracking issue #73230 for more details.

Background gradients now work alongside background images

Background gradients and background images no longer conflict. The gradient used to get silently overridden by the image; now they combine and display together. This applies to the Group, Verse, Accordion, Pullquote, Post Content, and Quote blocks.

Testing Steps

1. Add one of the supported blocks – for example, a Group block with some content inside.
2. In Styles, set a background image on the block.
3. On the same block, also set a background gradient.
4. Confirm both the image and the gradient show together in the editor, with neither cancelling the other out. 
5. Save and view on the front end; confirm both render together. 
6. Repeat on at least one other supported block (Verse, Accordion, Pullquote, Post Content, or Quote) and try a couple of different gradient/image combinations.

Expected: 

Each supported block – Group, Verse, Accordion, Pullquote, Post Content, and Quote – can display a background image and a background gradient at the same time, in both the editor and on the front end. 

Testing Instructions: 

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow PR #75859, #79391, #79840, #79841, #79842, #79843 for more details.

Image block — “Mark as decorative” toggle

The Image block has a new “Mark as decorative” toggle that hides an image from screen readers. Use it for purely decorative images (backgrounds, flourishes) so assistive technology skips them an improved experience for screen-reader users.

Testing Steps

1. Add an Image block and choose an image.
2. Open the block’s Settings sidebar and find the “Mark as decorative” toggle.
3. Turn it on.
4. Inspect the image’s markup and confirm it gets an empty alt (or role=”presentation” / aria-hidden, depending on output) so screen readers ignore it.
5. View the post on the frontend and confirm the decorative markup is present there too.
6. Turn the toggle off again, add meaningful alt text, and confirm the image is announced to screen readers once more.

Expected: 

With the toggle on, the image is hidden from screen readers (empty/presentation alt); with it off and alt text set, the image is announced normally.

Testing Instructions: 

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow PR #78064 for more details.

Editable blocks inside the Custom HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. block

The Custom HTML block can now keep editable blocks inside an otherwise static HTML structure (powered by a new innerContent block support). This is ideal for AI-generated or hand-built markup, where most of the HTML stays as-is but you mark just some parts a paragraph, an image — as editable. The editable inner blocks sit at their exact position in your markup but are locked: they can’t be moved, removed, or inserted, and they offer no alignment controls.

You add an editable block by writing its block delimiter inside the Custom HTML’s code, for example <!-- wp:paragraph -->…<!-- /wp:paragraph -->.

Testing Steps

1. Add a Custom HTML block to a post or page, then open its Edit HTML modal.
2. Paste this code — it has a Paragraph block delimited inside static HTML — and click Update: <div class="banner"><h1>Static heading</h1><!-- wp:paragraph --> <p>Editable paragraph</p> <!-- /wp:paragraph --><footer>Static footer</footer></div>
3. Confirm the paragraph renders at its position inside the static markup and is editable in place (click into it and type).
4. Confirm the paragraph cannot be moved or removed (no up/down movers, no Delete in its options menu) and offers no alignment controls.
5. Open the block’s inspector and confirm the inner blocks list appears, acting as a navigation aid to the editable parts.
6. Save the post and reload the editor: the saved markup should be identical to what you entered, and your paragraph edit persists at its position.
7. View the post on the frontend and confirm the full structure renders (the heading, the editable paragraph, and the footer).
8. Regression check: create a plain Custom HTML block with normal static content, edit and save it the markup should be unchanged. Note that scripts no longer run in the editor canvas preview (styles still apply), although they still run on the frontend.

Expected: Delimited blocks become editable in place inside the Custom HTML block, are locked against moving/removing/inserting, appear in the inspector’s inner-blocks list, and the saved markup stays byte-identical to what you entered. Plain static Custom HTML blocks remain unaffected.

Testing Instructions: 

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow PR #79115 for more details.

Embed block — embed shortcode transform

Pasting or converting an embed shortcode now produces a proper Embed block instead of leaving raw shortcode text behind.

Testing Steps

1. Open Post editor 
2. Switch to code editor.
3. Use an embed shortcode like the one shown in the screenshot.
4. Switch back to the visual editor.
5. Click on the “Convert to blocks” toolbar button on the classic editor.
6. Apply the transform and confirm the embed previews in the editor.
7. Confirm the shortcode is correctly transformed to the appropriate embed block.

Expected: 

embed convert cleanly into Embed blocks that preview in the editor and render on the frontend.

Testing Instructions: 

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow PR #77937 for more details.

Shortcode block — block-specific transforms

When the text inside a Shortcode block matches a registered shortcode (like gallery, audio, or video), the editor now offers a transform into the comparable block, making it much easier to modernise old shortcode-based content.

Testing Steps

1. Add a Shortcode block containing a known shortcode.
2. Use a supported shortcode like the one shown in the screenshot below.
3. Confirm a transform option appears to convert it to the matching block (Gallery / Audio / etc.).
4. Apply the transform.
5. Confirm the new block renders the same content.
6. Save and view on the frontend to confirm the output matches the original shortcode’s result.

Expected: 

Matching shortcodes offer a one-click transform to the equivalent block, and the converted block renders the same content on the frontend.

Testing Instructions: 

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow PR #77944 for more details.

What to Notice

While testing, keep an eye on:

• Could you find all the features? Could you figure out how to use them just from the interface?
• How did the workflows feel? Smooth and logical? Or were some slow, confusing, or broken?
• Did you  notice visual regressions in the editor, admin screens, or frontend?
• How did patterns, templates, and site editor changes behave when you changed style variations, or themes?
• Did you test any assistive devices or on-device accessibility settings (focus order, keyboard traps, missing labels, reduced‑motion, contrast settings)? How did the feature work under those conditions?
• Do you see PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php notices, warnings, or deprecations in logs or the debug console that weren’t there before? Did any show up on the front end, where visitors might see?

Make notes of anything that feels off—even if you’re not sure it’s a bug.

Where to Report Feedback

Please share everything that stands out — as a problem or a plus, or anything in between: issues, suggestions, and whatever else you find significant.

Choose any of these options:

• Post in the #core-test & #core channel in the Making WordPress Slack to discuss issues in real time.
• Create a tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket at https://core.trac.wordpress.org/ for WordPress Core issues.
• Open a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ issue in the Gutenberg repository for editor‑related bugs.

Include as much detail as you can in your report:

• WordPress version (e.g. 7.1‑beta1 or 7.1‑RC1).
• PHP version and database type/version.
• Theme and active plugins.
• Exact steps to reproduce the issue.
• Screenshots, screen recordings, and any error messages/logs you could capture.

Changelog

1.0.0 – Initial Post
1.0.1 – Added a review step to Apply Globally.
1.0.2 – Removed the “On This Day” dashboard widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user..

Props to @nikunj8866 for creating several feature testing guides and videos, and to @amykamala, @krupajnanda, @annezazu, and @nikunj8866 for the pre-publish review of this post.

#7-1, #call-for-testing, #core, #release-field-guide