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.
Please drop by any time in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. with questions or to help out.
Customizable Navigation Overlays are a new feature for WordPress 7.0 that gives you full control over “mobile” navigation menus using blocks and patterns.
We’re inviting the WordPress community to test this feature and share feedback. We’d love to hear from you by February 9, 2026 to allow time for refinements before the feature freeze.
Why This Change?
Mobile navigation overlays have been a significant pain pointPain pointPain points are “places where you know from research or analytics that users are currently getting hung up and have to ask questions, or are likely to abandon the site or app.” — Design for Real Life for WordPress users. Users have had very little control over the design and content of their mobile navigation menus. When someone taps a hamburger menu on mobile, they’ve been stuck with WordPress’s default overlay – no ability to customize branding, add promotional content, adjust styling, or control the layout.
This creates real problems:
Sites can’t maintain brand consistency on mobile
No way to add calls-to-action or promotional content in the mobile menu
Mobile navigation feels disconnected from the rest of the site design
Users resort to complex workarounds or custom code
Custom Navigation Overlays addresses this by giving users full control over their mobile overlay menus using the familiar 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.
What’s New?
Navigation Overlays enable users to:
Create custom mobile overlay menus using blocks and patterns
Control overlay design, content, and behavior – add branding, images, calls-to-action, and more
Manage multiple overlay variations – create different overlays for different contexts
Custom overlays are saved as template parts, which means they’re reusable components you can manage alongside your other theme templates. As such Themes can also provide their own Overlays suited to their particular design and use case.
This feature is targeting WordPress 7.0 and represents the first iteration of customizable navigation overlays. We’re shipping a solid v1 foundation that solves the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. user need, with plans to expand capabilities in future releases based on community feedback.
We’d Love Your Feedback
We’re inviting the WordPress community to test this feature before it ships in 7.0. Your feedback will help us:
Catch bugs and edge cases
Validate the user experience is intuitive
Ensure compatibility across themes and use cases
Identify what works well and what needs refinement
Timeline: We’d appreciate feedback by February 9, 2026 (this gives us time to address issues before the February 19 feature freeze)
A Navigation block inserted to access overlay controls
What to Test
We’ve outlined three testing scenarios below. You don’t need to test everything – pick what interests you or matches your use case.
Scenario 1: Create Your First Custom Overlay
Try this if you: Want to experience the feature as a first-time user
Steps:
Insert a Navigation block on a page or in a template
Look for the overlay customization controls in the block settings
Create your first custom overlay
Preview it in the editor
View it on the frontend in mobile view
What we’d love feedback on:
How easy was it to discover the overlay controls?
Was the creation process clear and intuitive?
Does the overlay look correct on mobile?
Scenario 2: Build a Custom Overlay from Scratch
Try this if you: Want to design a custom overlay with your own blocks and styling
Steps:
Create a new overlay starting with blocks (not a pattern)
Add various content: headings, images, buttons, navigation links, etc.
Style your overlay: colors, spacing, typography
Test submenu behavior
View on frontend mobile
Bonus: Try creating multiple overlay variations and switching between them.
What we’d love feedback on:
Can you build the overlay design you want?
Are the design controls sufficient?
Does switching between overlays work smoothly?
Scenario 3: Test Edge Cases
Try this if you: Want to help us find bugs and boundary conditions
Ideas to test:
Try creating an overlay without a close button – what happens?
Test with different WordPress themes
Delete a custom overlay and see how Navigation blocks handle it
Add multiple close buttons to one overlay
Test with complex block combinations
What we’d love feedback on:
Does anything break or behave unexpectedly?
Are error messages (if any) helpful?
How does the feature handle edge cases?
Testing Tip: Try Both Editor and Frontend
For any scenario you test, it’s helpful to check both:
✅ Editor experience – Does it work while editing?
✅ Frontend experience – Does it work on the live site (especially mobile)?
You can use browser DevTools device emulation or resize your browser to mobile width to test.
SEO and 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) Feedback Wanted
We’re actively discussing the technical implementation of overlay markup and would especially value input from SEO and accessibility experts.
The question: Where should the overlay markup be placed in the HTMLHTMLHTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites.?
If you have expertise in SEO or accessibility, we’d appreciate your perspective on which approach would best serve users. Feel free to share relevant standards, best practices, or real-world considerations that should inform this decision.
Comment on this post with your findings, or create 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 be the repository owner. https://github.com/ issues in the WordPress/gutenberg repository and link to them in your comment.
Helpful to include:
Browser and device/theme used
Screenshots or recordings (visual evidence is super helpful!)
Clear steps to reproduce any issues
Your assessment of severity (if reporting a bug)
Example:
Browser: Chrome 131, macOS
Theme: Twenty Twenty-Five
Issue: Overlay close button not visible on dark backgrounds
Steps to reproduce:
1. Create overlay with dark background
2. Add default close button
3. View on frontend mobile
Expected: Close button should be visible
Actual: White close button disappears against dark background
Severity: Medium - workaround is to add custom close button
[Screenshot]
Known Limitations (v1)
This is the first iteration of Navigation Overlays for WordPress 7.0. Some capabilities are intentionally out of scope for this release and will be considered for future versions:
Mega menus
Dialog-block reuse for overlays
Inline editing overlays directly in main canvas (currently must edit via template part editor)
We’re focused on shipping a solid foundation that solves the core user need. Future releases will expand capabilities based on community feedback and real-world usage.
Your feedback will help ensure Navigation Overlays provide a great experience for WordPress users managing mobile navigation. This is a v1 release, and your input will shape future iterations of the feature.
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.
The team discussed changes to the monthly newsletter format. The decision was made to remove the “tests to be done” section and replace it with a new “call for testing” section that aggregates requests from other groups. Additionally, the newsletter will include announcements, news, and ideas from team members. @mosescursor will comment on the related 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 be the repository owner. https://github.com/ issue with further details.
New Triage Guide
@sirlouen presented the diagram proposed by @juanmaguitar in the “Add TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. Keyword Triage Guide for Test Team Members” initiative. During the discussion:
@ozgursar raised concerns about whether bug reproduction should be included, noting it could be confusing.
@r1k0 commented that the guidance on what to write for expected results is not clear enough.
@sirlouen requested that team members add more comments to the GitHub issue to help refine the new guide.
@sirlouen expressed hope that the team can move toward an automated testing protocol in the future. Several ideas were discussed around improving the onboarding experience for new contributors:
@shazzad suggested adding a special keyword to identify easy tickets for new test team members.
@supernovia suggested the name good-first-test for this keyword.
@sirlouen had some concerns looking at the triage workflow: when a new test ticket appears in chat, a team member should triage and review it, removing the needs-testing keyword if the ticket cannot be tested, but leaving it if it can be tested. Placing the good-first-test keyword on tickets doesn’t seem to find a good place in this workflow. Further refinement is required to confirm that this keyword will truly fit.
@shazzad will open a ticket in the GitHub test-handbook repository to formalize this idea.
The team also discussed the need for weekly test team updates on current Needs Reproduction and Needs Patch Testing tickets. @mosescursor will handle this responsibility until @nikunj returns.
@mosescursor asked if @r1k0 would be joining the contribution day in Uganda on March 14. @r1k0 will check his schedule and confirm.
@sirlouen reminded the team that any AI tools used during testing should be noted in the footnotes of test reports.
@mosescursor will request huddle permission from the metaMetaMeta 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. team to facilitate future voice chats.
Mark your calendars! WordPress 6.8 is set to launch on April 15, 2025. WordPress 6.8 will be the first major release of 2025 and will focus primarily on being a polished and bug-fix release. Get ready for a more refined and seamless WordPress experience than ever before!
Testing early means fewer surprises for users down the line! Whether you have a few minutes or a few hours, your help in catching bugs early during the release cycle ensures a smoother upgrade experience for millions of users after the stable release. Every contribution counts and is deeply appreciated.
WordPress doesn’t require you to be a certified software tester or professional QA to contribute to testing; use WordPress as you normally would for your own needs. If you encounter any issues or feel something isn’t working as expected, please report them.
Not sure about the expected behaviour? No worries! Join the conversation on WordPress Slack or create a ticket on Trac, where a helpful global WordPress community is always ready to assist.
Recommendations for Testing WordPress 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./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 CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Features that Matter to You: Use your site for the purpose it was created. For instance, if you’re a blogger, running a social platform, or managing an e-commerce store, set up a staging site (ask your hosting provider if you’re unfamiliar with the staging site). 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., and continue using your site as you would daily. This will help you identify any issues that may affect your regular workflow. Take note of any issues or troubles you experience after the update. Do not test or update your live site with a beta version for testing purposes.
Use the General Checklist provided in the post below to verify that everything functions as expected after the update.
Ways to Test WordPress Beta Versions
There are multiple ways to test WordPress development or beta versions:
Playground
Playground is an easy and fast way to test beta or release candidateRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. versions of WordPress without setting up a full environment. You can quickly spin up a test environment using WordPress Playground.
Local Hosted Site
You can make use of software like Local or wp-env to create a local WordPress site. Once the site is ready, you can install the Beta Tester plugin to switch to the beta version of WordPress.
Once your site is up and running, you can use 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 to switch it to the development or beta version of WordPress. This plugin makes it easy to install pre-release versions of WordPress. To use the plugin:
Choose the 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. with Nightlies option, depending on what you want to test.
Click on Save Changes
After the changes are saved, you should receive the update notification. Kindly update your WordPress version.
For more detailed instructions, follow this guide.
Via WP-CLIWP-CLIWP-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/
If you prefer working with command-line tools, use WP-CLI to install a WordPress beta version quickly.
Steps:
Create a local WordPress site using your preferred method.
Once the site is set up, open your terminal and navigate to the root directory of your WordPress installation.
Run the following command to update to the latest beta/RC version:
wp core update --version=6.8-beta1
OR
wp core update --version=6.8-RC1
(Keep updating the version number as needed. E.g. –version=6.8-beta2)
This method helps you to switch between different versions quickly, making it easier to test specific builds.
Using a Staging Site
Create a staging site for your live 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. and update it to the WordPress beta/RC version. This lets you safely test the new version without impacting your live site. Make sure everything functions as expected before applying updates to your production environment.
Testing Patches
If you plan to test patches, follow these instructions to set up a WordPress development version locally.
Using Playground, you can also easily test individual Core tickets without installing any software in your system, and this is the fastest way to test any PRs.
If there is a specific PR in the wordpress-develop or gutenberg repo that you’d like to test in the browser, you can do so using the following links. Enter the PR number, and the rest will be taken care of.
If you want to quickly test the updated WordPress version’s compatibility with your site, please verify the following important checks. Enable debugging in wp-config.php to capture the warnings, errors or notices.
Update your theme and plugins to the latest versions.
Switch to the Beta/RC/Night build you want to test.
Check Site Health to see if there are any new errors or warnings.
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
Manually add media files.
Save the post
Observe the console for any issues.
Create a new page:
Add content
Verify its display in different browsers.
Verify its display in responsive mode.
Verify that the functional part is working as expected regardless of browser or device type.
Keep the browser’s developer console open 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.
Key Features to test
Editor
New default rendering mode for editor via post type supports
The 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 be the repository owner. https://github.com/ PR #69286 introduces a new approach to setting the default rendering mode in the WordPress block editor based on post-type support. This enhancement allows developers to define how content is rendered in the editor by specifying parameters within the support property of a post type.
Test Steps:
Install and activate any block theme. E.g 2025
Open a new page
Verify that it renders in a template-locked state.
Now, disable the “Show Template” in the 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. and reload the page.
Verify that it uses “post-only” as the default rendering mode.
Re-enable “Show Template” from the sidebar bar.
Open a post and confirm that it still renders in “post-only”.
Now, switch to a classic theme. E.g. 2011
Confirm that posts and pages both are loading correctly without showing the template.
Design Improvements
The design focus is refinement and fixing issues requiring design feedback. Let’s check them one by one.
Stylebook improvement for classic theme
The Style Book now provides a more structured layout, making it easier to preview and understand site colours, typography, and block styles.
Support is available for classic themes that either support editor styles via add_theme_support( 'editor-styles' ) or have a theme.json file. Each block example and style group is labelled for better clarity. For classic themes, the Style Book now supports site patterns, which have been relocated to Appearance > Design > Patterns for a more intuitive experience. Previously, patterns were listed under Appearance > Patterns.
Testing Instruction:
Please help identify potential issues and suggest areas for improvement by logging your feedback on #68036. Follow PR 66851 for more details about this fix.
Reset Button for Color Control
A new Reset button has been added to the colour control, allowing users to quickly revert the color changes.
Testing Instruction:
Test Steps:
Create a page and a paragraph block.
Add text/background/link colors to the paragraph.
Observe the change in the color.
Now, hover/focus on the element and observe the presence of the reset(-) button.
Clicking on the reset button resets the applied color.
If you encounter any issues or have suggestions, feel free to drop your feedback in this ticket #41866.
Zoom-Out Mode Enhancements
Users can now apply different section styles and designs directly from the toolbar.
Testing Instruction:
Test Steps:
Navigate to Appearance > Editor
Edit the page and choose the pattern.
Enter into zoom-out mode.
Observe the toolbar with a newly added icon.
Verify that there should be no shuffle button present and that the change design option should be visible.
Click on the icon, and it will change color based on the different styles.
Follow PR #67140 for a detailed understanding of the implementation path.
Improved Font Picker Previews
The font family list in Global Styles now previews each font directly in the dropdown. This provides a better visual indication of how the font will look before applying it. Testing Instruction:
The outcome of the Image manipulation method is now better communicated in the block editor. The success notices are now displayed at the bottom of the editor. The notices also come with a handy Undo link to revert to the original if necessary.
Testing Instruction:
Test Steps:
Create a post or page, insert the Image block and select an image.
Try different editing options for Image – edit, zoom, crop, rotate.
A correct message should be displayed after processing the media.
Also, confirm you can easily undo changes using the snack bar action.
Both these changes are part of different PRs #67314 and #67312
Block supports: Show selected item in font family select control. (#68254)
Fix: Ensure consistency in editor tools for navigation buttons and delete options. (#67253)
Global Styles: Fix handling of booleans when stabilizing block supports. (#67552)
Support for Speculative Loading
We are excited to announce that WordPress 6.8 includes native support for speculative loading, a feature designed to enhance site performance by enabling near-instant page load times.
What is Speculative Loading?
Speculative loading leverages the Speculation Rules API to automatically prefetch or prerender certain URLs on a page based on user interactions, such as hovering over a link. This proactive approach allows subsequent pages to load more quickly when users navigate to them.
Default Configuration
WordPress 6.8 configures the speculative loading feature by default to prefetch URLs with a conservative eagerness setting. This means the browser will prefetch resources only when there is a strong indication that the user intends to navigate to a particular link, balancing performance benefits with resource usage.
Testing Instruction: Customisation via Filters
While there are no options or user interface controls to modify the behaviour of speculative loading as we have in the Speculative loading plugin, developers do this by customising its functionality using the newly added filters with different combinations of values.
Please check this comment for a more detailed explanation of how to test.
Use a browser that supports the Speculation Rules APIAPIAn 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. (e.g., Chrome 108+, Edge 108+) because not every browser supports it. Please refer to caniuse.com for a comprehensive support overview of speculation rules.
Impact on Existing Plugins
With the integration of speculative loading into the WordPress core, the existing Speculative Loading plugin that provides similar functionality will be updated to use the core implementation. The plugin will continue to use its approach to prerender URLs with moderate eagerness, now by adjusting the default configuration set by Core.
We encourage developers and site administrators to test this new feature in their environments and provide feedback. Your insights are invaluable in ensuring that speculative loading enhances performance effectively across the diverse WordPress ecosystem.
Please check this ticket #62503 for more information about this enhancement. Feel free to comment and share your feedback/queries/issues regarding performance and speculative loading integration.
Polishing the Query LoopLoopThe 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.
Fix: Sticky Posts Not Working with Default Query Type
Previously, sticky posts did not appear at the top when using the default query type in the editor. This issue has now been fixed.
Testing Instruction:
Test Step:
Have at least one sticky post on the blog
Open the template using the editor’s query loop block (index, archive, etc.).
Notice that the sticky post is at the top.
Open the front of the site and see the sticky post at the top.
Please refer to this #68570 ticket for more details about this fix.
“Ignore” Option for Sticky Posts
A new “Ignore” option for Sticky Posts has been added to the Query Loop block, giving users more control over including or excluding sticky posts in the query. It adds a new option for the Query block’s sticky post setting: “Ignore,” which doesn’t prepend sticky posts at the top but displays them in the natural order of the query.
Testing Instruction:
Test Steps:
Have at least one sticky post on the blog.
Create a page and add a simple Query block.
Confirm that the sticky post is displayed at the top by default.
Change the sticky post setting to “Ignore”.
Confirm that it’s now displayed in natural order.
If you find any issues while testing this enhancement, please feel free to share your findings here in issue #66221
Set Depth Limit for Query Loop
The Query Loop block retrieves posts from all levels, and there is no built-in option to filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. only top-level posts as they do not have a parent field that can be set to 0.
The current solution partially addresses the issue by allowing “parents”: [0] to be set programmatically but not providing a 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. option. This PR includes an example Query markup for testing. As for the UI, the Parent filter will be updated once a suitable design proposal is available. Please share your feedback by commenting here on the issue #68620
Removal of Redundant Sticky State
The redundant sticky state in the Query Loop block has been removed for a more streamlined user experience.
Testing Instruction
Test Steps:
Insert a Query Loop and select a pattern with some posts.
Open the inspector controls of the block.
Verify that the Post Type field is working as expected:
The “Sticky Posts” field is visible when “Post Type” is “Post“
The “Sticky Posts” field is hidden when “Post Type” is “Page“
Query Total: Add interactivity.clientNavigation block support
With RC1 we have introduces the support for interactivity.clientNavigation within the Query Total block. This enhancement enables the Query Total block to interact seamlessly with client-side navigation, ensuring that the displayed total number of query results updates dynamically as users navigate through content without requiring the full page reloads.
Testing Instruction:
Test Steps:
Create a page
Add Query Loop block
Within the Query Loop, insert a Query Total block.
In the Query Loop block, toggle off “Reload full page” from right sidebar.
In the Query Total block, change display type to “Range display”.
Save the change and open the page in the front end
Observe that client navigation is now working as expected.
“Refining Data Views” allows the customisation and improvement of how data is displayed and managed within the WordPress editor, particularly by utilising the “Data Views” feature which allows users to filter, sort, and organise content more effectively through various options and settings, ultimately leading to a cleaner and more efficient workflow when working with large amounts of data on a website.
WordPress 6.8 release comes with additional improvements and fixes, as mentioned below.
Unify layout behaviour
This update aims to improve the user experience by providing a more intuitive interface. The implementation includes adjustments to the existing components to integrate the new media field seamlessly. This enhancement is part of the ongoing efforts, and to keep up with the progress, please check this issue #67391
Testing Instruction:
Test Steps:
Open the different data views for Pages, Templates, and Patterns
Check the design of the different layouts for List, Grid and Table
Check how the “properties” menu works with the different layout
Add confirm dialogue before delete
The existing ‘Permanently Delete’ action lacked clarity and did not include essential safeguards, such as a confirmation modal. This absence increased the risk of accidental deletions. To improve the user experience and minimize errors, this PR introduces a confirmation modal, ensuring users confirm their intent before deleting selected posts.
Testing Instruction:
Test Steps:
Go to the WordPress admin dashboard area.
Go to Appearance > Editors > Pages
Click on the page that you want to delete
The page will move to the TrashTrashTrash 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.
Now, select the trashed page and use the “Permanently Delete” option.
Confirm the deletion in the modal dialogue.
Observe the success or error notices appearing for both individual and bulk deletion options.
This PR #67170 introduces a density option to the table layout while allowing layouts to define specific controls. Instead of a generalized density abstraction, this approach ensures better clarity and avoids confusion for table layouts.
Testing Instruction
Test Steps
Go to the WordPress admin dashboard area.
Go to Appearance > Editors > Pages
Go to Pages/Templates/Patterns
Change the layout to Table View
Now, click on the settings icon
Observe the newly added Density option
Please play around with all three options, “Comfortable, Balanced, and Compact,” and share your feedback if you have it.
Use badge component in data view grids
This update improves consistency in the Site Editor by using a standardised badge for synced patterns. It ensures a uniform look while keeping the existing functionality unchanged. The new Badge component is integrated into the DataView grids to enhance consistency and maintainability.
Testing Instruction:
Testing Steps:
Navigate to the WordPress dashboard
Go to Appearance > Editors > Patterns
In the Patterns list, identify any patterns labelled as “synced”.
Confirm that these “synced” patterns display a badge utilizing the new Badge component, ensuring consistency in design and functionality.
Set Featured ImageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. directly from block
WP Core now has a new toggle set under the settings for the post. If a feature image is not set for the post, enabling the toggle control will set the selected image as the feature image for that post. Follow the steps mentioned below.
Testing Instruction
Test Steps:
Create a new post.
Add an image block.
Enable the “Set this image as featured image” toggle from the settings.
Verify that the selected image is set as the post’s featured image.
As the first step of running Interactivity API event listener callbacks asynchronously by default (see #64944), a utility function called withSyncEvent is introduced. Developers should use this function to wrap event handlers that require synchronous access to event data or methods, such as event.preventDefault(). For other event handlers that don’t need synchronous event data, the system can defer their execution, enhancing overall performance by reducing the load on the main thread.
Follow the testing instructions mentioned here in the description of PR #68097
Block 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. API
The Block Hooks API is an extensibility mechanism that allows you to dynamically insert blocks into block themes. In WordPress 6.8, work will continue on improvements to Block Hooks.
This release also includes a fix for the Post ExcerptExcerptAn 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. block to display an extra “>” character at the beginning of the excerpt when no custom excerpt is set and the Query Loop block is added to a page. Additionally, for sticky posts without a custom excerpt, the beginning characters of the excerpt are missing.
Please follow the testing instructions mentioned here in issue #68903
We have also updated the document of the block hooks section of the block registration reference guide. Please check issue #65454 for more details on what has been updated.
Security enhancements
The underlying algorithm used to hash and store user passwords in the database has been changed in WordPress 6.8 from phpass portable hashing to bcrypt. Application passwords, user password reset keys, personal data request keys, and the recovery mode key will switch from using phpass to the cryptographically secure but fast BLAKE2b hashing algorithm via Sodium. The full details of this change can be found in the announcement post.
These changes should work and should be invisible to users. Passwords and security keys that were saved in prior versions of WordPress should continue to work after updating to 6.8. Users don’t need to change or reset their passwords; logged-in users should remain logged in, and their sessions should remain valid.
Here are some testing steps that can be taken:
Remaining logged in after the update
Ensure you have remained logged in to your account after updating to 6.8
Confirm that logging out and back in again works as expected
Confirm that the user_pass field for your user account in the wp_users table in the database has been updated — after logging out and back in again it should be prefixed with $wp$2y$ instead of $P$
Password resets
Start with the “Lost your password?” link on the login screen and initiate a password reset
Click the confirmation link sent to your email inbox
Follow the process of resetting your user password
Confirm you can log in with your new password
Personal data requests
Log in as an Administrator
Initiate a data export from Tools -> Export Personal Data
Click the confirmation link sent to the email address and confirm that the export gets triggered as expected
Remaining logged in after the update
Ensure you have remained logged in to your account after updating to 6.8
Confirm that logging out and back in again works as expected
Confirm that the user_pass field for your user account in the wp_users table in the database has been updated — after logging out and back in again, it should be prefixed with $wp$2y$ instead of $P$
Password resets
Start with the “Lost your password?” link on the login screen and initiate a password reset.
Click the confirmation link sent to your email inbox
Follow the process of resetting your user password
Confirm you can log in with your new password
Personal data requests
Log in as an Administrator
Initiate a data export from Tools -> Export Personal Data
Click the confirmation link sent to the email address and confirm that the export gets triggered as expected
Additional performance improvements
The additional performance improvements are also part of the WordPress 6.8 release, and details are provided in their respective issues/PRs, as explained below.
Did you notice any performance issues, such as slow loading or lag?
Were there any visual inconsistencies or layout issues across different browsers or devices?
Did the drag-and-drop functionality work as expected, especially in patterns?
Did the preview mode accurately reflect how the content appeared once published?
Did what you created in the editor match what you saw on your site?
Did you observe any other 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) issues like –
Colour contrast or focus management?
Did it work properly using only a keyboard?
Did it work with a screen reader?
Did it function smoothly on a mobile device?
What aspects of the experience did you find confusing or frustrating?
What did you especially enjoy or appreciate?
What would have made site building and content creation easier?
Where to Report Feedback
If you find any issues but aren’t sure if it’s a bug or where best to report the problem, share them on the alpha/beta forums of WordPress. If you are confident that you found a bug in WordPress Alpha/Beta/RC, report it on Core Trac for rollback auto-updates and the Gutenberg GitHub repo for every other feature.
Note-taker and facilitator selection for the next meeting We encourage all members to contribute to the team chat, and we now welcome Note Takers and Facilitators. This is a great time to get involved in the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. test team. Have you recently joined, and you don’t know where to go? Start here (No Skills Required)
“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. testers” for the new Test Contributor Pathway course
Creating a new page in the handbook with a “template” for Test Chats
Following this year’s nominations and voting period, we are pleased to announce our new Test Team Reps for the 2025-2026 term! 🎉 Join us in welcoming Moses Cursor Ssebunya and Nikunj Hatkar to represent the Test team!
Moses Musoke Ssebunya is a WordPress professional with over six years of experience in development, testing, and community engagement. Since 2018, he has contributed as a developer, translator, and tester, and has led teams on various WordPress projects.
An active member of the WordPress Community Team, Moses has spoken at WordCamps in Masaka, Entebbe, and Nairobi, and organized local meetups in Uganda.
Moses is passionate about improving WordPress through testing and fostering collaboration across the community.
Nikunj is a WordPress developer with expertise in 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 development, APIAPIAn 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. integrations, and web solutions.
An active contributor since 2024, he has participated in multiple WordPress teams and helped organize local meetups. Passionate about open-source, he enjoys problem-solving and sharing knowledge.
As a Test Team Representative, he wants to focus on improving WordPress quality, reporting bugs, testing releases, and supporting the community.
At present, the Test Team operates with limited active resources, and a significant portion of the workload is handled by a tiny number of contributors. This creates bottlenecks and increases the risk of fatigue for those who remain consistently involved.
Over time, participation patterns within the Test Team have changed. Many past members are no longer actively involved, which reflects the absence of clear long-term participation expectations in earlier years. As a result, previous team members were recognized under practices that did not clearly distinguish between short-term involvement and sustained contribution. These recognitions will be respected, as they were granted under the rules and understanding in place at that time.
Starting in 2026, the Test Team will introduce clearer participation guidelines. Earning “emeritus” status will be based on sustained and consistent contribution over time, rather than short-term or representative involvement alone. New members are expected to remain actively engaged, to the best of their ability, over an extended period.
Towards an easier-to-join but easier-to-leave team
Historically, joining any WordPress team is moderately easy and difficult at the same time.
Mainly there are two ways to join:
The easy way: joining as a team representative. There is a window every year if you want to join this way, just for the sake of accomplishment, and you’re good to move on after that year. Many members have nominated themselves to try to witness if, by any chance, they got selected. The sole difficulty of this was the fact that only two members could join (three members in some teams), and in numerous instances, gaining reputation was not even relevant: by manipulating the vote system, some managed to join hideously.
The hard way: an extremely rare way, where some members do an epic task and they are recognized as team members for a real merit. Exceptional tasks are things like triaging a couple hundred tickets or managing dozens of meetings, scrubs, or any other activity in the given team. This path is much less common and requires significant dedication and effort, making it the true recognition of commitment and contribution. For the past decade, less than a handful of members have been able to achieve the Test Team role through this method for many reasons, including poor guidelines to clearly help direct efforts.
To address these challenges, we must redefine the criteria for becoming and remaining a Team member, emphasizing sustained contribution and active participation over time rather than just initial entry.
The proposal comes with lowering the barrier for joining “the hard way” but dismissing those “reps” as the sole way to access. We should not forget that representatives are not team leaders; it’s just a shared commitment to support the team over a year-long period. Ideally, already established contributors should be taking this role instead of new members aspiring to get the role just to get the accomplishment or, even worse, the badge.
Lowering the entry barrier will facilitate the access of many more members to the team, but at the same time, new rules should come by to help remove the non-emeritus team members that have not fulfilled a consistent expectation over time. This way we will switch the sense of accomplishment with a sense of duty. Only those that stay for long enough will receive the “emeritus status,” as already introduced, which means preserving the status forever. More details will be commented on in next year’s meetings and further discussed in the Test Handbook GitHub issue tracker.
Announcing: The Test Team Training Program
To support these new guidelines and help members develop the skills needed for meaningful contributions, we are excited to announce the launch of the Test Team Training program. This initiative aims to provide structured learning opportunities and resources to empower both new and existing members to engage more effectively with testing activities.
Starting in January 2026, we will be covering 4 main areas during the 4-week program duration
Development of handbook and training resources.
Collaboration and communication within the team.
Testing fundamentals and best practices.
Meetings and scrub management.
Members willing to join the program should be available to invest at least 20 hours during the program’s month (expecting 2-hour live sessions + 3 hours of individual practice per week). “Graduating” will not necessarily warrant a spot on the Test Team but will provide precise guidance on the steps to get there with ease.
Be aware that this is not a mentorship but a guided trainer’s training. Instead, it focuses on equipping participants with precise knowledge and tools to effectively contribute to and support the team’s testing efforts. We may consider future trainings depending on the results. It will be open only to 5 spots. Even though, theoretically, Team members don’t need to be technical for this training, a basic level of technical familiarity (i.e., 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 be the repository owner. https://github.com/, WordPress testing workflows, and reading code) is required. In case that there are more spot requests than the 5-cap limit, we will be selecting by technical skill level.
If you have come this far and you want to join, please fill out the following form:
The starting date will probably be the 8th or 15th of January, but it is still pending confirmation. Each of the two one-hour live sessions will most likely be around 3 or 4 PM GMT Tuesdays and Thursdays, and they won’t be recorded.
A new feature is introduced in Gutenberg 21.8RC: the ability to hide blocks from the frontend.
This option provides more flexibility for working with content and layouts. Instead of deleting or moving a 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. you don’t want published, you can temporarily hide it. The block remains in the editor, but it will not appear on the live site until the visibility is switched back on.
Why this matters
Makes it easier to experiment with different layouts without losing content.
Allows draft or placeholder content to stay visible in the editor but hidden from site visitors.
Encourages non-destructive editing and smoother collaboration.
Creates a foundation for future enhancements
Key Changes to Observe
In the editor,
It adds a menu item to the block settings options to change the block’s visibility.
“Hide”: A “Hide” option appears on each block by default
“Show”: Clicking on “Hide”, the block setting toolbar should display the “Show” option.
In the List view, the visibility of multiple blocks can be changed simultaneously.
Select the block and click on the “Hide” control from the toolbar settings
Observe that the block is no longer visible in the editor, and the “Show” control should be toggled on for that block (Observe the List view)
Check the change in the front end, and the block should be hidden
Now, turn off the hide setting in the editor
The block should reappear in the editor and the front end
Nested blocks: Place a few blocks inside a Group/Columns block and hide the parent.
Confirm that all inner blocks are hidden
Multiple instances: Hide different blocks across the page and verify that only the chosen ones are excluded from the frontend.
Testing Instruction
Since this feature is newly introduced, it needs testing, and feedback is especially valuable.
Please share:
Did the toggle behave as expected?
Did you run into inconsistencies between the editor and the frontend?
Were there any issues with nested, synced, or reusable blocks?
Your input will help refine this feature as it moves toward the WordPress 6.9 release.
Follow #71203 PR for more details. If you observe any related issues, please feel free to report them here.
📈Performance / Asset Check
Hidden blocks should not appear on the frontend, and their related CSSCSSCSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site./JS should no longer be actively used. Optionally, you can verify this via the Network tab or CSS Coverage in DevTools. Visible blocks must continue loading normally. On small pages, coverage differences may be subtle; the key point is that hidden blocks do not add frontend markup or assets. Check #9213 PR for more details. If you would like to verify this, follow the steps in the comment.
If you’re unsure whether what you are experiencing is a bug, you can ask in the #outreach channel on the WordPress SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
Change Log
1.0.0 Initial Post
1.1.0 Add Performance check
Props to @wildworks@psykro for pre-publish review of this post.
Hello and welcome to another edition of Week in Test, the place where contributors of any skill level can find opportunities to contribute to WordPress through testing. You can find the Test Team in #core-test.
Table of Contents
Calls for Testing 📣
Calls for Testing can originate from any team, from themes to mobile apps to feature plugins. The following posts highlight features and releases that need special attention:
Collaboration: add 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.-level comments:
Merging of Test Handbook in 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 be the repository owner. https://github.com/
For the last few weeks, a good number of test contributors embarked on the journey of reviewing our new Test Handbook based on GitHub. The Process has been concluded successfully with the merging.
We want to inform that the Test Handbook is officially synced. There might be a couple of bugs and things that are not looking good pending to be fixed.
Feel free to give it a check here, and if you find any bugs, go to the GitHub repository and report them. You can send a PR with the fix or simply send the issue, and we will check it.
We are currently under review of the home page and the PR is here for review.
We also need a new draft for the Team Reps for discussion in the next Test chat.
Here’s a roundup of active tickets that are ready for testing contributions. Did you know that contributions to the Test Team are also a fantastic way to level up your WordPress knowledge and skill? Dive in to contribute, and gain coveted props 😎 for a coming release.
1. WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Testing
a. Patch Testing 🩹
Who? All contributors (not just developers) who can set up a local testing environment. Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
It is necessary to confirm if the bug is happening under multiple conditions and environments, using the bug reproduction report in order to validate the issue.
The following tickets have been reviewed and milestoned, and need testers to check the instructions and manually test if the issue is reproducible, the provide a bug reproduction report:
2. GutenbergGutenbergThe 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/ Testing
The following tickets have been filed reporting a known bug and needs testers to manually test, then provide feedback through a bug reproduction report that the issue can be reproduced.
All contributors (not just developers) who can set up a local testing environment. Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed, and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
Nothing to test yet this week
Profile Badge Awards 🎉
Congratulations to the recipients of the Test Contributor Badge 🎉 @dhruval04
WordPress 6.9 is planned for December 2, 2025, with RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1 beginning November 11, 2025.
Upcoming Meetings 🗓
🚨 There will be regular #core-test meetings held in 2025.
Hello and welcome to another edition of Week in Test, the place where contributors of any skill level can find opportunities to contribute to WordPress through testing. You can find the Test Team in #core-test.
Calls for Testing 📣
Calls for Testing can originate from any team, from themes to mobile apps to feature plugins. The following posts highlight features and releases that need special attention:
Collaboration: add 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.-level comments:
Merging of Test Handbook in 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 be the repository owner. https://github.com/
For the last few weeks, a good number of test contributors embarked on the journey of reviewing our new Test Handbook based on GitHub. The Process has been concluded successfully with the merging.
We want to inform that the Test Handbook is officially syncing. There might be a couple of bugs and things that are not looking good pending to be fixed.
Feel free to give it a check here And if you find any bugs go to the GitHub repository, and report them. You can send a PR with the fix or simply send the issue, and we will check it.
Here’s a roundup of active tickets that are ready for testing contributions. Did you know that contributions to the Test Team are also a fantastic way to level up your WordPress knowledge and skill? Dive in to contribute, and gain coveted props 😎 for a coming release.
1. WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Testing
a. Patch Testing 🩹
Who? All contributors (not just developers) who can set up a local testing environment. Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
Who? Any QA or 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/preface.php. developer contributors who can (or are interested in learning how to) build automated PHPUnit tests. Why?Automated tests improve the software development feedback loopLoopThe 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. for quality and backward compatibility.
2. GutenbergGutenbergThe 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/ Testing
The following tickets have been filed reporting a known bug and needs testers to manually test, then provide feedback through a bug reproduction report that the issue can be reproduced.
All contributors (not just developers) who can set up a local testing environment. Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed, and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
WordPress 6.9 is planned for December 2, 2025, with RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1 beginning November 11, 2025
Upcoming Meetings 🗓
🚨 There will be regular #core-test meetings held in 2025.
You must be logged in to post a comment.