WordPress 7.0 — the first 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 April 9, 2026.

WordPress 7.0 was originally planned for release on 9th April, Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/ at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia 2026. However, the release has been slightly postponed to give the team additional time to fine-tune advanced features like real-time collaboration and to ensure the release meets high standards of stability and quality.

With the launch of 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, it’s time to start testing everything. That’s the best way to make sure this WordPress is stable, reliable, and easy to use for users across the globe.

Early testing is critical.

It finds 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.0 or not.

Stay informed!

The WordPress 7.0 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.0 into the strongest, most polished release ever. 

And with the new features coming in 7.0, 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 use WordPress as you would every day (on a test installation, of course!)

Run WordPress hard. Take it through processes that mimic your projects, workflows, and experiments. Try to break things.

Notice something unexpected? Run into a bug? Is a feature not behaving the way you thought it would? Please consider reporting it.

Not sure what the expected behaviour 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. If you’re comfortable with the ticket system, you can also create a ticket on WordPress TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.. 

New tester? You have the global WordPress community at your service. Everyone in it is happy to welcome and support you. 🌍

Again, every report, question, or observation you submit makes a difference and helps improve WordPress for hundreds of millions of users.

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. 
• 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 at 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., which lets you install pre-release versions of WordPress.
4. Switch to the development or beta version of WordPress:
   1. Navigate to Tools > Beta Testing.
   2. Choose between Bleeding Edge 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, depending on what you want to test.
   3. Click Save Changes, and 
   4. Update your WordPress version.

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.0-beta1

Or

wp core update --version=7.0-RC1

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

With WP-CLI, you can install several different versions and switch between them on the fly. 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.0 lands in your production/live environment.

Testing Patches

Maybe you don’t need to test an entire version of WordPress, but you do need to test one or more patches.

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

If you want to quickly test the updated WordPress version’s compatibility with your site, please verify the following checks:

First, update your WordPress to the Beta/RC version, enable debugging in wp-config.php, and update your theme and plugins.

• Ensure plugins and themes didn’t deactivate automatically after the update.
• Check the WordPress Site Health tool for any new warnings or issues.
• Confirm there are no layout breaks or misaligned elements.
• Test links and permalinks to ensure there are no 404 errors.
• Verify that posts, images, and media are displayed correctly.
• Ensure the sitemap and robots.txt files are functioning properly.
• Ensure full access to the admin dashboard without errors.
• If your site has custom blocks, create content in 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. and edit existing content.
• Create a new post: add content, copy-paste text, and manually add media files. Save the post and observe the console for any issues.
• Create a new page, add content, and check its display in different browsers.
• Open the browser’s developer console and check for any errors, warnings, or notices.
• Open the error log file and check for notices, warnings, and fatal errors.
• Review user roles and permissions to ensure they remain intact.
• Verify that any scheduled posts or automated tasks (like backups) still function as intended.
• Ensure all integrated services (like payment gateways or analytics) are operational.
• Open your site in different browsers and verify that all functionalities work as expected.
• Check site performance and loading speed after the update.
• Verify 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 such as keyboard navigation, contrast, and screen reader behavior where possible.
• Test form submissions (contact forms, checkout forms, login forms, etc.).
• Confirm media uploads, image editing, and gallery functionality work properly.
• Test theme customization settings (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. or Site Editor) for stability.

WordPress continues to work reliably for the diverse global community that depends on it.

If anything fails here, it can directly impact revenue, so prioritise fixing these issues before updating production.

👉 Key Features to Test

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.

Visual revisions in WordPress 7.0 let you see and restore past versions of a post directly inside the editor, with clear visual highlights of what changed. You get a new “Revisions” view instead of being taken to a separate screen, with a timeline/slider to move between older and newer revisions. The content canvas shows visual diffs where added text is highlighted in green, removed text in red, and formatting changes like links or bold in yellow, while changed, added, and deleted blocks are visually marked so you can quickly see which parts of the page changed. In this mode, you can inspect and restore a revision, but you cannot edit content directly, keeping the experience focused on review and recovery.

Testing Steps

1. Create content and revisions
   • Create a new post or page.
   • Add a few different blocks (Paragraph, Heading, List, Image).
   • Make several changes and click Update each time (add text, remove text, change formatting, add/remove blocks).
2. Open the in‑editor revisions view
   • In the editor, open the post 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. (Document/Settings).
   • Click the Revisions link/count.
   • Confirm you stay in the editor and see a dedicated revisions 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. and slider.
3. Use the slider/timeline
   • Move the slider to older and newer revisions.
   • Confirm the canvas updates to show the selected revision and that the current revision is clearly indicated.
4. Check visual diffs
   • Verify:
     • Added text is highlighted in green with an underline.
     • Removed text is highlighted in red with strikethrough.
     • Pure formatting changes (e.g., turning a word into a link, making it bold) are shown in yellow (outline/underline).
   • Confirm that changed/added/deleted blocks are visually distinguished from unchanged blocks.
5. Scroll markers/navigation
   • Look for markers along the scroll area that show where changes exist.
   • Click a marker and confirm the view jumps roughly to the changed area.
6. Selection and non‑editing
   • Click on blocks in the revision view.
   • Confirm you can select and inspect them, but cannot type, add new blocks, or move blocks around.
     

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

Font Library Support for More Theme Types

WordPress previously introduced the Font Library to allow users to upload, manage, and apply fonts directly within WordPress without relying on themes or additional plugins. With updates targeted for WordPress 7.0, this functionality is expanding beyond block themes to better support classic themes as well.

This enhancement means site owners using classic themes can now access font management features in a more consistent way, similar to how media assets are handled. A dedicated Fonts page now appears under Appearance → Fonts for classic themes (not just block themes), where users can upload, activate, and manage fonts centrally.

Once added, these fonts become available within block editor typography controls — for example, selecting a font family from the Paragraph block settings — helping provide a more unified typography experience across different theme types.

Testing Steps 

Verify Font Library Availability in Classic Theme

1. Install and activate a classic theme (e.g., Twenty Twenty-One or similar).
2. Navigate to Appearance → Fonts.

Expected:

• The fonts page should appear even with a classic theme.
• No UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. breakage or missing styles.

Upload Custom Fonts

1. Go to Appearance → Fonts.
2. Upload a supported font file.
3. Activate the uploaded font.

Expected:

• Font uploads successfully.
• The font becomes available in the library.
• No errors in console or server logs.

Use Fonts in Block Editor

1. Create or edit a post/page.
2. Add a block (e.g., Paragraph).
3. Open Typography settings → Font Family.
4. Select the uploaded font.

Expected:

• Font appears in the dropdown.
• Font applied correctly in editor preview.

Frontend Rendering Check

1. Publish/update the post.
2. View on frontend.

Expected:

• The selected font displays correctly.
• No fallback or styling conflicts.

Responsive editing mode

The Responsive Editing Mode introduces enhanced control over how content appears across different device sizes directly within the block editor. This feature allows users to selectively hide blocks based on screen type — desktop, tablet, or mobile — helping create more tailored and optimized viewing experiences without requiring custom CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. or theme-level adjustments.

With this capability, site owners and content creators can better manage responsive layouts, ensuring that specific content elements display appropriately depending on the user’s device. This is especially useful for optimizing readability, improving mobile usability, and delivering cleaner layouts across varying screen sizes.

Testing Steps 

1. Go to the WordPress dashboard and click on Page/Post.
2. Open the page where you want to modify block visibility.
3. Click on the specific block that you want to hide for a particular screen size.
4. Click the three dots (⋮) icon in the block toolbar to open additional options.
5. From the dropdown menu, choose the Hide option.
6. Select the device type (Desktop, Tablet, or Mobile) where the block should be hidden, then save the page.
7. View the page on the frontend and confirm that the block is hidden on the selected screen size.
8. Verify Using List View
   • Click the List View icon in the top toolbar.
   • Locate the block in the list.
   • A crossed eye icon will indicate that the block is hidden on one or more devices.
9. Modify Hide Settings (If Needed)
   • Click the block with the crossed eye icon.
   • The Hide Block Settings panel will open, allowing you to review or adjust visibility preferences.

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

New Admin Improvements

WordPress 7.0 includes a visual refresh of the admin interface aimed at modernizing wp-admin, improving consistency with the block editor design system, and enhancing overall usability. This update focuses primarily on styling and UI polish without major functional changes, so testing should emphasize visual consistency, plugin compatibility, accessibility, and regression checks.

Testing Steps 

1. Review major admin screens such as Dashboard, Posts/Pages list, editor screens, Settings, Media Library, and Plugins/Themes pages to check visual consistency, spacing, typography, button alignment, and notice styling.
2. Test plugin compatibility by activating commonly used plugins (e.g., WooCommerce, SEO plugins, form plugins, or custom admin plugins) and verify that admin layouts, buttons, tables, and forms display correctly.
3. Verify core workflows like creating/editing posts or pages, uploading media, updating settings, and navigating across admin sections to ensure no functional regressions.
4. Perform accessibility checks, including colour contrast, keyboard navigation, focus states, readability, and screen reader behaviour.
5. Test responsive admin behaviour by resizing the browser or testing on tablet/mobile widths, ensuring menu collapse, tables, and buttons remain usable.
6. Observe performance aspects such as admin page load time, layout shifts, console errors, or unusual delays.
7. Conduct regression checks by comparing behaviour with previous WordPress versions to confirm workflows, settings, and media functionality remain stable.
   (Tip: Open a new Playground instance with an older version of WordPress, like 6.9 and compare )
8. Report any issues such as broken layouts, plugin conflicts, accessibility regressions, inconsistent styling, or performance concerns.

Follow #64470 for more details.

Customizable overlay for the navigation block

WordPress 7.0 introduces Customizable Navigation Overlays, a new feature that provides greater control over mobile navigation menus directly within the block editor. Previously, mobile menu overlays offered limited customization options, often restricting users to default layouts and styling.

With this enhancement, users can design fully customized navigation overlays using blocks and patterns — allowing them to add branding elements, calls-to-action, images, and tailored navigation structures. These overlays are saved as reusable template parts, enabling consistent design across themes while also allowing theme authors to provide predefined overlay designs.

Testing Steps

1. Insert a Navigation block on a Template.
2. Select the Navigation block and look for the ‘Settings’ inside the right panel.
3. Look for the ‘Overlay’ customisation controls and create a ‘Custom Overlay’.
4. Preview it in the Editor.
5. View it on the Frontend in mobile view.

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

Real-time Collaboration 

Real-time collaboration is the crowning feature of the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ Project phase 3, and this is the first iteration to land in Core. You can call it RTC for short.

But before it can get there, RTC needs you! (And your friends!) Every part of this groundbreaking functionality, from front-end usability to literal php functions, plus database calls, 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. endpoints, and more, needs to run this first implementation through its paces.

In short, please ride this hard. Try to break everything! That’s how the folks who’ve been working on this will know it’s good enough to be in Core.

Testing steps

• Install WordPress 7.0 Beta 1 on a server that somebody else can reach. 
• This should probably be a new installation. maybe on a local network or on a staging server, or something in between—not a production server, but also not a local installLocal Install A local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer. on a single machine.
• In the plugin, navigate to Settings > Writing and toggle on “Enable real-time collaboration.”
• Open a post for editing. Start with a regular post, of course, but remember that pages are also posts, and custom post types are posts too! There are some exceptions, which you’ll find below. 
• Invite a friend or colleague (or two or ten!) to edit the same post.
  • Consider joining a video call and sharing your screens so you can each see both experiences.
  • Or, collaborate with yourself! To do that, open your install in a separate tab and log in as someone else. See if you can edit as both people!
  • Another option: open your site on two machines on the same network.
• If you have some, use real content—real text and images, other data sources and other media. See if you can use your usual workflows.

What to expect

• Real-time collaboration only works when you’re editing posts in the block editor and site editor. It won’t function on other admin screens.
• Classic post 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 do not sync. Using these boxes still works, but your collaborators will not see updates in real time. They might even overwrite each other’s changes.
  • Without looking at the code, it’s not always obvious whether a post meta box is Classic (persisted using a save_post hook) or modern (integrated with the Gutenberg data store). Many plugins still use Classic post meta boxes.
• Most blocks are compatible. Blocks are synced via their attributes, which means that most blocks support real-time collaboration by default. Some blocks might use local state when working with user input, which can result in issues during real-time collaboration.
  • The core/freeform (Classic) block is currently incompatible.
• Plugins that integrate with the block editor might have issues. Behavior with plugins is some of the most important feedback you can give. 
• Collaborator cursors disappear in the Show Template view.
• Collaborating on the same block can have issues. Please test it anyway, but expect quirkiness around cursor placement. Your feedback may well speed up the fix!
• Syncing happens over HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. polling, so it’s not instant. It could feel laggy sometimes—please report this! As well, if it feels much smoother at some points than at others, please report that. Performance will directly affect how the community takes to RTC long-term.

What to notice

About overall functionality:

• Did real-time collaboration work the whole time? 
• Did you get disconnected? Did it ever feel unresponsive to the point that it interrupted your work?
• Did you lose any content? How about duplication?

In real-life workflows, could you collaborate:

• On custom blocks?
• Inside a plugin’s UI?
• In the site editor?
• On a large document?
• If you added more than one user?

How did RTC do on accessibility? Did it work:

• Only using the keyboard?
• With a screen reader?
• On a mobile device?

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

New blocks & updates

WordPress 7.0 adds some new blocks:

• Icon
• Breadcrumbs 

The Icon block lets you add one or more icons and style them in limited ways, with more options to come in the future.

Testing steps

1. Open a post or page.
2. Insert the Icon block.
3. Try out the options you see. 

The Breadcrumbs block ships with two options: to show the Home link and select the separator. For now, the block only works with hierarchical post types.

Testing steps

1. Open a hierarchical post (like a page)
2. Insert the Breadcrumbs block.
3. Toggle the option to show the Home link. Does it show up on the page?
4. Toggle the Home link off. How does that work?
5. Experiment with choosing separator options. 
6. Report your findings.

Plus, three blocks are getting updates:

• The Gallery box adds a lightbox to switch between images.
• The Cover block will support external video.
• The Grid block is getting new controls.

Client side Media processing in the browser

WordPress 7.0 introduces Client-side media processing, leveraging the browser’s capabilities to handle tasks, like image resizing and compression, for smoother image processing. This enables the use of more advanced image formats and compression techniques, and reduces demand on the web server, providing a more efficient media handling process for both new and existing content, and supporting smoother media workflows.

With so many options and enhancements in WordPress 7.0 Beta 1, this is still only the beginning. You can expect future releases to be even better.

You can check the following details for clear and helpful test instructions.

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/preface.php Compatibility Update in WordPress 7.0 

WordPress 7.0 raises the minimum supported PHP version to 7.4, which means sites still running PHP 7.2 or 7.3 will not receive this major update and will remain on the 6.9 branch. To stay current and secure, site owners should plan to upgrade their PHP version with their hosting provider (ideally to PHP 8.3+) and test their site on staging before updating to WordPress 7.0. This change helps WordPress take advantage of newer PHP features and performance improvements while keeping support focused on actively maintained PHP branches; you can read more details in the official announcement here: 

Dropping support for PHP 7.2 and 7.3 – Make WordPress Core

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 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 stood out—as a problem or a plus, or anything in between—issues, suggestions, and whatever else you found 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 trac 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.0‑beta1 or 7.0‑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 – Removed Tab Block Details

1.0.2 – Updated info for WP release delay

Props to @marybaum for working on the New Blocks and Real-time Collaboration sections.
Props to @anveshika for working on Customizable Overlay and Responsive Editing Mode sections.
Props to @amykamala, @muddassirnasim, and @wildworks for the pre-publish review of this post.

Login to Reply<\/a><\/li><\/ul><\/div>","commentTrashedActions":"