The Test Team helps manage testing and triage across the WordPress ecosystem. They focus on user testing of the editing experience and WordPress dashboard, replicating and documenting bug reports, and supporting a culture of review and triage across the project.
WordPress 7.0 is scheduled to release today, and you may have some questions or doubts related to testing, updating, compatibility, or how the release process works.
Below are some questions that may help contributors, developers, pluginPluginA 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./theme authors, site owners, and general WordPress users better understand the WordPress 7.0 release and testing process.
What is WordPress 7.0 RC5?
WordPress 7.0 RC5 (Release CandidateRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 5) is a near-final testing version of WordPress 7.0. At this stage, the release is considered feature complete, but community testing is still needed to identify remaining bugs, regressions, compatibility issues, and usability concerns before the final release.
When will the final version of WP 7.0 be released?
These resources can help contributors, testers, plugin/theme authors, and site owners better understand what is included in WordPress 7.0 and how to test related functionality.
Why is testing RC5 important?
Testing RC5 helps improve the stability and quality of WordPress 7.0 before it reaches millions of websites worldwide. Community testing helps uncover issues across different plugins, themes, hosting environments, browsers, devices, and workflows that may not appear in limited testing environments.
I already tested my site with WordPress 7.0 during BetaBetaA 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. 2 & Beta 3. Do I still need to test with RC5?
Yes — RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. testing is still extremely valuable even if you previously tested earlier beta versions. During the RC phase, many bugs and fixes have already been added since Beta 2 and Beta 3.
I did not get a chance to test any Beta or RC versions with my existing WordPress site. Should I directly update once WP 7.0 is officially released?
It is not recommended to update a production siteProduction SiteA production site is a live site online meant to be viewed by your visitors, as opposed to a site that is staged for development or testing. immediately without any prior testing, especially if your site uses custom code, multiple plugins, custom themes, or complex integrations.
Even though WordPress 7.0 is widely tested by the community before release, every website environment is different. It is always safer to test before updating production.
I am not a technical person, but I have a WordPress site. Should I avoid updating to the latest WordPress version?
No. Keeping WordPress updated is important for security, performance, bug fixes, and compatibility improvements.
A good approach is to ask your hosting provider to create a staging site (a copy/replica of your live website) with the latest WordPress version installed. There, you can test your normal day-to-day workflows before updating your production site.
For example:
if you run a photo blog, try uploading/editing/deleting photos
if you run an eCommerce store, test checkout and orders
if you run an LMS site, test courses and student access
Real-world testing on a staging site can help identify issues before updating your live website.
Do I need technical knowledge to help test?
No. You do not need to be a developer or know how to code.
Even testing your normal day-to-day website workflows can be extremely valuable, whether you use WordPress for example:
an eCommerce store
a Learning Management System (LMS)
a business website
a blog
a portfolio
or any other type of website
Real-world usage testing helps identify issues that may not appear in limited development environments.
I just learned that a new WordPress version is coming, but I did not test my site with any Beta or RC versions. Is it okay to wait before updating after the official release on May 20 until I test my site?
Yes, absolutely. It is completely fine to wait and test your site before updating your live/production website to a major WordPress release.
Do not test directly on live / production websites.
What should I test first?
Start with workflows you use most often.
Suggested areas:
BlockBlockBlock 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. editor
Site editor
Publishing workflow
Media uploads
Theme compatibility
Plugin compatibility
Menus/widgets/navigation
Responsive/mobile behavior
AccessibilityAccessibilityAccessibility (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)
Performance
What should plugin and theme authors focus on?
Plugin and theme authors should carefully test:
Installation and activation
Updates
Editor integration
Frontend rendering
Settings screens
Custom blocks
APIs and hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.
Styling/layout behavior
Fatal errors or warnings
Compatibility testing before release helps reduce user issues after launch.
What kinds of issues should testers look for?
Helpful issues to report include:
Fatal errors
Broken layouts
Missing UIUIUI 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. controls
Failed saves/updates
JavaScriptJavaScriptJavaScript 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 issues
Accessibility regressions
Performance slowdowns
Mobile/responsive issues
Unexpected behavior changes
Plugin or theme conflicts
Even small usability problems can be valuable feedback.
How can I tell whether something is actually a bug?
A good approach is to:
Reproduce the issue multiple times
Test with unnecessary plugins disabled
Switch temporarily to a default theme
Compare behavior with WordPress 6.x if possible
If something worked previously but behaves differently in 7.0 RC5, it is worth reporting.
How do I report a bug?
Before reporting:
Try reproducing the issue consistently
Document exact reproduction steps
Collect screenshots or screen recordings if possible
A WordPress Release Party is a live, coordinated session where contributors gather in the Make WordPress Slack to help test, monitor, and celebrate a new WordPress release as it’s being packaged and published. It’s both a working session and a community event, where people collaborate in real time to catch last-minute issues, validate fixes, and ensure the release goes smoothly.
What happens if the WordPress release team finds a critical bug during release party? Will the new version still be released?
Not necessarily. If a critical issue is discovered during release testing, the release team may decide to delay the final release until the issue is investigated and resolved.
The stability and safety of WordPress sites always take priority over releasing on a fixed date.
Need More Help or Have Questions?
If you still have any questions or doubts beyond the topics covered above, feel free to ask in the comments below or reach out in the #core and #core-test Slack channels.
Every test, bug report, reproduction step, screenshot, verification, and piece of feedback helps improve WordPress for millions of users worldwide.
Thank you to everyone helping test and contribute to WordPress❤️
WordPress 7.0 — the first major releaseMajor ReleaseA 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. The new release date is May 20, 2026.
With the launch of BetaBetaA 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 schedulepage has everything you need to know about the latest pre-release builds and milestones.
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 TracTracTrac 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 CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. Versions:
Test the CoreCoreCore 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 EnvironmentA 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.
Once your site is up and running, install and activate the WordPress Beta Tester pluginPluginA 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.
Switch to the development or beta version of WordPress:
Navigate to Tools > Beta Testing.
Choose between Bleeding Edge or Point ReleaseMinor ReleaseA 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.
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.
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 blockBlockBlock 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 accessibilityAccessibilityAccessibility (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 (CustomizerCustomizerTool 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 RevisionsRevisionsThe 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
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).
Open the in‑editor revisions view
In the editor, open the post sidebarSidebarA 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 headerHeaderThe 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.
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.
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.
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.
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
Install and activate a classic theme (e.g., Twenty Twenty-One or similar).
Navigate to Appearance → Fonts.
Expected:
The fonts page should appear even with a classic theme.
No UIUIUI 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
Go to Appearance → Fonts.
Upload a supported font file.
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
Create or edit a post/page.
Add a block (e.g., Paragraph).
Open Typography settings → Font Family.
Select the uploaded font.
Expected:
Font appears in the dropdown.
Font applied correctly in editor preview.
Frontend Rendering Check
Publish/update the post.
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 CSSCSSCSS 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
Go to the WordPress dashboard and click on Page/Post.
Open the page where you want to modify block visibility.
Click on the specific block that you want to hide for a particular screen size.
Click the three dots (⋮) icon in the block toolbar to open additional options.
From the dropdown menu, choose the Hide option.
Select the device type (Desktop, Tablet, or Mobile) where the block should be hidden, then save the page.
View the page on the frontend and confirm that the block is hidden on the selected screen size.
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.
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
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.
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.
Verify core workflows like creating/editing posts or pages, uploading media, updating settings, and navigating across admin sections to ensure no functional regressions.
Perform accessibility checks, including colour contrast, keyboard navigation, focus states, readability, and screen reader behaviour.
Test responsive admin behaviour by resizing the browser or testing on tablet/mobile widths, ensuring menu collapse, tables, and buttons remain usable.
Observe performance aspects such as admin page load time, layout shifts, console errors, or unusual delays.
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 )
Report any issues such as broken layouts, plugin conflicts, accessibility regressions, inconsistent styling, or performance concerns.
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
Insert a Navigation block on a Template.
Select the Navigation block and look for the ‘Settings’ inside the right panel.
Look for the ‘Overlay’ customisation controls and create a ‘Custom Overlay’.
Preview it in the Editor.
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.
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
Open a post or page.
Insert the Icon block.
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
Open a hierarchical post (like a page)
Insert the Breadcrumbs block.
Toggle the option to show the Home link. Does it show up on the page?
Toggle the Home link off. How does that work?
Experiment with choosing separator options.
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.
AI in WordPress
You can refer to this post for detailed guidance on testing AI features 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:
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.
Open a GitHubGitHubGitHub 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
1.1.0 – Updated RTC details, new timeline, AI in WP section.
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.
As you’re aware, WordPress 7.0 is slated to be the first major release of 2026, with the official release date set for April 9, 2026. As we gear up for this important milestone, our Test team will be shifting gears a bit.
Starting from our upcoming weekly Patch Testing Session, we’ll be running a Test Scrub for WP 7.0 instead of the usual Future Milestone Tickets. These scrubs will focus specifically on tickets and issues related to the WordPress 7.0 milestone. It’s a great opportunity to contribute to this major releaseMajor ReleaseA 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. and make a tangible impact on the final product.
We’ll primarily concentrate on tickets that are tagged Has Patch or/ Needs Testing for the 7.0 milestone. You can find these tickets in the 7.0 report on Trac. As the release moves through BetaBetaA 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. and RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge., we’ll also highlight key features and regressions that need focused testing.
Interested in Leading a Test Scrub?
Did you know that anyone can lead a Test Scrub at any time? Yes, that means you can!
If you’re interested in leading a scrub, please reach out in the #core-test Slack channel with:
If you’re planning a scrub that’s specifically focused on WordPress 7.0, that’s fantastic! We can add it to our schedule so the rest of the team knows to join in. Leading a scrub is a great way to contribute.
Let’s Contribute Together
This is a perfect chance to get involved with the major release of WordPress 7.0, learn more about the release process, and help ensure the quality and stability of WordPress. Your contributions will make a difference, so join us for the Test Scrub sessions and be a part of this exciting release.
Thank You ❤️
Thanks to everyone contributing time, testing, feedback, and expertise. Community testing plays a critical role in making each WordPress release successful.
Let’s work together to make WordPress 7.0 a smooth and high-quality release.
After one month of very intensive activity, we have finally reached the end of the test team program. We would like to thank all the participants for their dedication and hard work throughout this period. The program has been a great success in many areas, and we have gathered valuable insights and feedback that will help us improve our whole contribution onboarding process.
During the program, we started with a total of 9 participants, but after some expected dropouts, we ended with 6 members, with most participants doing a fantastic job during the entire process. They were involved in tasks such as testing, documentation improvements, leading meetings, and a lot of feedback to support the team’s growth.
In a dedicated SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ channel, we have been able to work very closely with the participants, gathering information about their experience through the process and also sharing the progress of this program. There was no clear starting program structure, but one happened to begin shaping as weeks went by that could be described as follows for the record:
Program Weekly Structure
The first week was focused on onboarding all members on the testing protocol as soon as possible, because one of the main targets was to go through a significant amount of tickets through the program period.
During the second week, we started introducing the meeting protocols, both for patch testing scrubbing and how to run the weekly test meetings with the corresponding agenda and summary post publishing. We also started to gather feedback on the testing protocol because the initial test results started to pop up.
For the third week, we switched the focus to documentation improvements, and we started to gather feedback on the meeting protocols and keep it up on the testing part. The contributor pathway video program began to come together.
Finally, for the last week, we tried to clear up all the final questions and analyze the current state of WordPress in correlation with the testing team to set future goals for the coming months.
Program Results
Overall, the program has exceeded our expectations in terms of engagement and results. Some goals were shared with the participants in the first interview, but from the experience we had from past programs, we knew that generally these goals were challenging to meet and could not be met. However, in this case, we have been able to achieve most of the goals and even exceed some of them. Here are some of the key results we have achieved:
Testing Reports
At the beginning of the program, there were a total of 487 tickets with the needs-testing label. By the end of the program, this number has dropped to 264, which is a significant decrease of almost 50%. This is by far one of the biggest achievements. We are pleased to observe that the protocol has been refined to a point that members were able to go through tickets at an excellent pace, understanding the whole process with proficiency. This will probably translate into a more efficient process in the future.
Documentation Improvements
Improving internal protocol documentation is something that requires more experience and time inside the team. However, we have been able to gather a lot of feedback and proposals for documentation improvements in our GitHub repository, which is a great starting point for the future. We have already started working on some proposals, and we hope to have them published in the following weeks.
The Crown Jewel: Test Contributor Pathway in Progress
One of the main goals of this program was to create a video training with a clear pathway for future contributors. We are delighted to announce that the program is almost completed, and we are planning to have it ready in a couple of weeks. A lot of feedback has been gathered through the program, and soon there will be an announcement in case anyone wants to join the “betaBetaA 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. program” to test the training and provide feedback before the official launch.
Participant Engagement Analysis as a Blueprint for Future Test Team Aspirants
We believe that sharing the results of the program participants could be useful for future WordPress contributors to understand which level of engagement is expected from them if they want to be part of the Test Team. And furthermore, to discover the different ways they can contribute to the team.
1. Ozgur (@ozgursar): Worked on a total of 68 testing reports, drove a test-chat and started leading to a documentation improvement regarding email testing. For the next few weeks, we expect the docs page to get published and a patch testing scrubbing meeting to be led to complete the whole circle. He is the first participant proposed to join the Test Team and continue his journey with us.
2. Huzaifa (@huzaifaalmesbah): Worked on a whopping total of 89 testing reports, which has been massive, and also proposed a documentation improvement regarding the `Getting started for testing` page structure. The only thing he has missed is leading some different meeting sessions, but there is already one scheduled for next week, and we are sure that with all the knowledge he has now, he is more than ready to lead more sessions in the future. He is the second participant suggested for joining the team.
3. Juanma (@juanmaguitar): He has been extremely active leading proposals for documentation improvements and providing a ton of feedback during all sessions, including a triaging guide, test-chat protocol guide, and some tips on post-tag improvement during a test-chat session. He has also led one test-chat session, but the only downside is that he has only been involved in testing 3 tickets, clearly the only weaker point that we hope could be improved in the following weeks to be somewhat on par with the rest of the participants. He is the third participant proposed for joining the team, and we are sure that with a bit more involvement in the reporting part, he can be a great asset for the team.
4. Erick (@r1k0): He worked through a grand total of 52 testing reports and also led one of the patch testing scrubs. There is only one thing that he has missed to go through the whole process, and it is the documentation improvement work and jumping into a couple more meeting leading sessions, but we are sure that he is more than ready to do it in the following weeks. He is the fourth participant recommended for joining the team, and we hope he jumps into the documentation part as soon as possible to be able to be on the team with a more complete profile.
5. Shazzad (@sajib1223): He was already active as a test team contributor before the program, but during the program, he has been able to consolidate many doubts he had about the test team protocols. He was able to run a patch testing scrub, but still in the other areas he has been lagging a bit. With no documentation proposals yet, only 10 tickets, and no test-chat sessions, we hope he can get quickly up to speed in the following weeks to be able to join the Test Team officially.
6. Mohammed (@mohkatz): He has been the last participant that has attended the whole program sessions, but unfortunately, he has not met the minimal requirements. With no testing reports, no documentation proposals, and no meeting-leading sessions. Hopefully, if he gives the team more time, he can get up to speed in the following weeks and be able to join the Test Team in the near future.
As I commented in the beginning, the other 3 participants that were selected dropped out in the beginning of the program for different reasons, and we hope that they can get involved in the future if they’d like to.
Future Directions and Organizer Personal Thoughts
As the organizer, I can’t stress anymore that this program has gone great, but simultaneously, I have to acknowledge that it has been very exhausting to organize. Running future programs like this is uncertain, and probably more organization and resource gathering will be required to be able to make it happen again in the following months. The dedication required from the organizers and participants is very high. Not only the two hours required for the live weekly sessions, but also the time to go through questions in the Slack chat, manually review most of the reports done and the documentation proposals, and also the time to create the training ideas.
Results of a program like this are proven to be excellent, but we need to find a way to make it more sustainable for the future. Luckily, now we have a couple of members onboarding in the team now and some additional ones probably soon, and we hope that they can take some of the leading load that has been driven by the current members in all testing areas, including, maybe, running future programs like this one.
Testing for backend upgrades, refactors of code, and overall any new feature that cannot be “touched or seen” regularly feels very challenging for most WordPress developers.
Sometimes unit-testing can do part of the heavy lifting, especially when having expertise in TDD, as a great deliverable could be provided.
The problem with unit-tests is that sometimes they are completely biased to our thoughts and ideas. It’s extremely difficult to think outside the box (especially when you are absorbed into a development that takes most of our attention), and this could potentially leave behind some scenarios you have not considered testing.
Adding up, when finally code is delivered, including sometimes those unit-tests, the rest of the people who are going to review it will not have the full understanding of the problem, with all the nuances, edge cases, or scenarios that could pop out of your resulting code.
As a WordPress developer, you have to consider that other reviewers in the team could range from a coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. committer with 15 years of code to a brand-new testing contributor out of a WordCampWordCampWordCamps 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. willing to start lending a hand. And getting them to review if the unit tests are right, or even to review the code and add new unit-tests for more edge cases is, in numerous instances, even for the most experienced reviewers, a hard task and something to avoid.
Here is why a Testing Use-Case could become really handy for these scenarios, a paradigm of testing that could be easily learned and applied and would help further progress many reports with patches that have been stuck for ages.
Let’s dive into the Testing Use-Case
Ideally, from a Testing perspective, the best code refactor, patch, upgrade, or feature is the one that actually addresses a problem you are already having.
For example, as a patch creator, you can find any of these scenarios:
Have a theme or a pluginPluginA 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. that is missing this functionality.
Find a deprecation notice in the logs.
Find an error in code that requires not only a quick fix but a whole revamp of the code.
Have a real-life requirement by any real stakeholder in our business or life in general, and we can express the entire demand down to the last detail.
These are all examples of Testing-Use Cases
But what happens if you don’t have any of those? What if you are a code freestyler that likes to sort things before they actually happen? Or maybe you have been developing somewhere else and out of sudden you think about an alternative fix that could be improved, despite not really having a real-life example to showcase our idea?
Here is where building a Testing Use-Case becomes handy.
Ideas to Build Your Testing Use-Case
Not it’s time to put some examples of the most common issues that were found lately and how implementing a Testing Use-Cases could help to move forward the patch and overall any report that could potentially get stuck.
The Hook
One of the most common reports with troubles to be tested, and many end up in the “pending box” because of new HooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.. Most hooks come out of a specific need from a dev, but for some reason, many devs fear that explaining their use-case could feel “agendistic” and not usable by the majority. Also, it’s very common that there is almost always a workaround using outlandish PHPPHPPHP (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 functions that bypass many standards and are not ideal by any means to achieve the same result as what a hook could provide us. So it’s very common that Hooks fade into oblivion.
Ideally, the #1 Testing Use-Case is, by far, explaining your business scenario without fearing any critique. Say you have a client that is paying you a big ticket, and you need that damned hook to get that attribute to do that selective filtering for the membership plugin you are building. This is totally fine if you need this hook for a commercial case. You can think that your case is unique and explanation will reveal it, but if you feel the need for this hook and there is no other straightforward way to achieve the same result without workarounds and hacks, it should be enough. Explaining the alternative solutions that were investigated will support your case. You may think that adding a hook to code is a simple thing, but when it is added, there will be no way to remove it or make changes that will break backwards compatibility, so the hook should be in the right place when it is definitely needed and have the right name and parameters. In addition, it should be documented in the code and in the Field guide and other documentation later. That one line of code requires a lot of support to happen.
Now to create the Testing Use-Case we have two options:
You can actually provide some of the code of that plugin you are building that showcases the feature where the new hook you are willing to implement is going to be applied.
If you would rather not showcase your code for copyright dilemmas with your client (funny in a GPLGPLGPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples. environment, but we all know that this still happens), reproduce a minimal MVPMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia version of what you are willing to achieve, mocking some data or building a hydration function to fill whatever content is required to display the issue, and creating a very simple plugin that delivers that and uses that hook and executes successfully.
Choose whatever you prefer. But be aware that what is actually problematic is making your way through it without explaining much, without any testing at all, and despite the hook being super simple, straightforward, and unlikely to be problematic at all, this always leads to distrust and leans towards the forgotten zone where it will never be reviewed and integrated into the core. It’s always better to be transparent and clear of what needs to be done in a GPL environment, and in the worst case, discuss the feasibility and maybe a better clean code alternative if possible.
There is a rule in the WordPress community: never refactor if you don’t have a good reason for this. This is mainly because it takes many resources to test and debug issues coming from the refactor, and most code reviewers are busy enough just with the regular bugs to be fixed and pending improvements to be implemented to invest time in this protocol, so refactoring could be important but not as critical as other topics.
But very occasionally, there could a good reason for a code refactor, for example, an upcoming PHP deprecation.
In these cases, the best scenario, unfortunately, is waiting for the deprecation notice reports to appear, and start fixing from there, one by one. Bear in mind that deprecations take ages to be converted into unsupported features; hence, waiting is probably the best and easiest bet.
But what if you are a restless soul and like to have everything bleeding edge updated?
The following steps are recommended after the patch has been built (or before):
First, identify which core functions you have modified. If there are unit-tests already, you can edit them to cover your new code; otherwise you could always build them later.
Consider that the current function was working as-is with the current premise. You should start building a very simple plugin that uses this old premise with all the functions you modified, test them, and display the results.
After that, you will think about your new premise and again, in the same plugin, apply it once more to all the functions you modified.
Remember that both, before and after, you should be passing the test with the new premises. Yes, with a unit-test you are doing this. But, as it was commented in the beginning, unit-tests can become very convoluted (because they are not generally designed for simplicity, but for heavy-lifting the future-proof of the whole system). On the other side, a plugin can be elegant, simple, and easy to showcase all we want to test. Any coder, regardless of his coding level, will probably be able to inspect it, understand it, and maybe think in more edge cases based on what he sees. It’s a new paradigm of simplicity and support for your peer reviewers. And perhaps the difference between a lost into oblivion patch or a patch that will be reviewed comfortably and steadily. As a rule of thumb, it’s easier to port a test use-case plugin to unit-tests than the other way around.
This categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. is like a hodgepodge because here you could find very different examples, and it’s going to be very difficult to make a general assumption on how to always proceed. But some rule of thumb could apply here, similar to the two previous sections:
If you have a real use case, a feature required by your client, or a snippet of code that can prove your enhancement, this will be sufficient. You simply need something more than unit-tests, that again, can be biased. Something that can be replicated in the WP front-end or admin panel and be tested with real data, not just with the mock samples from the unit-testing framework. Finding any of these is going to be the ideal scenario for most cases.
If, for some reason in life, it happens that you have come to this enhancement almost out of nowhere, while reviewing some other thing or for whatever other reason, a plugin that proves the new feature is clearly needed. The steps are very similar to the previous section, “Code Refactors” but adapting to the potential new functions we have developed.
Finally, the crown’s jewel of backend patches. In fact, most devs in the performance team are relatively familiar with this; hence, not much to be explained here for them. But just some general ideas for those who are still not very familiar with this.
A performance upgrade must factually test that there is a performance upgrade. It’s not enough with “before this it took 2 seconds and not it takes 1.” Real data that could be deployedDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. in multiple computers, environments, etc. is required, and really show that there is a real performance improvement.
For this, you will need to write a plugin that does, at minimal, these two things:
A hydration system to generate X number of whatever we need to test. If a WP_Query with 10K posts should be tested, then a hydration plugin that actually creates those 10K dummy posts for us is required. If there is a plugin out there that works and does this, refer to it. Don’t suppose we all know it.
A plugin that, actually, makes use of those 10K posts and tests this performance improvement with functions like microtime and get_num_queries (including SAVEQUERIES)
This could feel pretty obvious, but these two parts are essential to building a Testing Use-Case for performance upgrades. And it’s still surprising the massive number of times that they cannot be found in the Performance tickets. Simply don’t expect anyone to write them for you. Take the lead and send it the whole pack by yourself: the patch + the plugin with performance tests. Otherwise, there is a big risk that the ticket ends forever in the forgotten box of unreleased patches.
More examples in the future will be provided as they become available because some categories, like the Back-End Enhancements and New Features, certainly need them.
If you have any comments, any questions, or any ideas to improve this guide on how to build your Testing Use-Case, please comment.
Props to @oglekler and @audrasjb for helping review this article and offering feedback
You must be logged in to post a comment.