Month in Test: August 03, 2026

Hello and welcome to another edition of Month 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

  1. Calls for Testing 📣
  2. Test Handbook📘
    1. Merging of Test Handbook in Github
  3. Weekly Testing Roundup 🤠
    1. 1. WordPress Core Testing
      1. a. Patch Testing 🩹
      2. b. Bug Reproduction
      3. c. Test Team Issues
    2. 2. Gutenberg Testing
      1. a. Gutenberg Bug Reproduction Testing
      2. b. Gutenberg Patch Testing
  4. Profile Badge Awards 🎉
  5. Read/Watch/Listen 🔗
  6. Upcoming Meetings 🗓

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:

Test Handbook 📘

Merging of Test Handbook in GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/

For the last few months, 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

Weekly Testing Roundup 🤠

Bi-Weekly update: Test Team Update

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 skills? Dive in to contribute, and gain coveted props 😎 for a coming release.

1. WordPress CoreCore Core 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 (15) 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:

b. Bug Reproduction

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 (133) have been reviewed and milestoned, and need testers to check the instructions and manually test if the issue is reproducible, then provide a bug reproduction report:

c. Test Team Issues

Here are the current activities being discussed in the Test Team Github:

  1. We need to review the Test Team Issues. If you have a possible solution, comment in the Issue or submit a PR.

2. GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ Testing

👋Want to contribute to WordPress/Gutenberg? If you have a bug or an idea, read the contributing guidelines before opening an issue. If you’re ready to tackle some open issues, we’ve collected some good first issues for you.

a. Gutenberg Bug Reproduction Testing

The following tickets (14) 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.

b. Gutenberg Patch Testing

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 (1) 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:

Profile Badge Awards 🎉

Congratulations to the recipients of the Test Contributor Badge 🎉

@khushdoms, @jsmansart, @ankitkumarshah, @soyebsalar01, @poojapadamad, @gaurangsondagar, @manhar, @westonruter, @khushi1501

– Kindly find the Contribution Guidelines here

Read/Watch/Listen 🔗

  1. WordPress Ecosystem Announcements
  2. Test Team Announcements
    • Weekly Patch Testing Scrub: Second and Fourth Thursday of the Month at 15:00 UTC
    • Weekly Test Chat: Third Thursday of the Month at 15:00 UTC
    • Monthly Voice Test Chat: First Thursday of each month at 15:00 UTC
  3. Call for Testing

Upcoming Meetings 🗓

🚨There will be regular #core-test meetings. The schedule is being worked on and final schedule will be shared after finalizing the discussion

Current 2026 Schedule:

Interested in hosting a <test-scrub>? Test Team needs you! Check out Leading Bug Scrubs for details, or inquire in #core-test for more info.

props to @sajib1223 @huzaifaalmesbah @nikunj8866 for peer reviewing this post

#core-test, #fse-outreach-program, #gutenberg, #make-wordpress-orgupdates

Thank You to the WordPress 7.0 Test Contributors

WordPress 7.0 is here, and it wouldn’t have been possible without the incredible effort of the testing community. Behind every stable release is a dedicated group of people who download betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. versions, apply patches, reproduce bugs, and report what they find. They are the safety net that catches issues before they reach millions of WordPress users.

This post is a celebration of those people.

7.0 Testing, By the Numbers

These numbers were compiled using the WordPress Test Contribution Tracker, an automated tool that scans TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets, classifies test contributions, and identifies new contributors. If we missed your contribution or a number looks off, let us know in the comments – we’ll gladly fix it. 

During the WordPress 7.0 release cycle, the testing community achieved something remarkable:

427 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Trac tickets were tested
132 unique contributors participated in testing and bug reproduction
89 of them were new contributors — testing WordPress for the very first time and without a Test Contributor badge yet
113 contributors tested patches directly
34 contributors helped reproduce confirmed bugs
25+ countries across 6 continents were represented

That’s 67% of all test contributors being completely new to WordPress testing. If that’s not a sign of a growing and healthy community, we don’t know what is.

A Global Effort

Testing WordPress is truly a worldwide effort. During the 7.0 cycle, contributors joined in from 25+ countries across 6 continents, working across time zones and languages to make WordPress better for everyone.

🇮🇳 India led the way with 47 contributors — more than a third of all testers. 🇧🇩 Bangladesh followed with 15 contributors, and 🇺🇸 United States contributed 11. Rounding out the top countries: 🇩🇪 Germany (4), 🇫🇷 France (3), 🇪🇸 Spain (3), 🇵🇭 Philippines (3), 🇯🇵 Japan (2), 🇦🇺 Australia (2), and 🇺🇬 Uganda (2).

Contributors also joined from 🇰🇪 Kenya, 🇵🇰 Pakistan, 🇧🇹 Bhutan, 🇩🇿 Algeria, 🇳🇱 Netherlands, 🇦🇹 Austria, 🇹🇳 Tunisia, 🇪🇬 Egypt, 🇻🇳 Vietnam, 🇵🇹 Portugal, 🇳🇵 Nepal, 🇮🇹 Italy, 🇸🇪 Sweden, and 🇨🇭 Switzerland — each with 1 contributor proving that even a single test makes a difference.

Every Contribution Counts

We want to recognize every single person who tested a ticket, left a “reproduced” comment, or tried a patch during the 7.0 cycle. Whether you tested 36 tickets or just 1, you made a difference.

Here’s the full list of all 132 contributors who participated in testing or reproduction for WordPress 7.0:

@369work @abcd95 @abdullah17 @abduremon @adnanhyder @agnieszkaszuba @alh0319 @alexodiy @amesplant @amin7 @andrewssanya @ankitkumarshah @arkaprabhachowdhury @audrasjb @benniledl @berislav.grgicak @chexee @darshitrajyaguru97 @dhruvang21 @dhrumilk @dilip2615 @dlh @dmsnell @donmhico @drysand @ekla @ellatrix @emptyopssphere @fabiankaegy @fakhriaz @gaisma22 @gaurangsondagar @gauri87 @gautammkgarg @gulamdastgir04 @hbhalodia @hmbashar @huzaifaalmesbah @iamadisingh @ibrahimriaz @im3dabasia1 @immeet94 @jabir20 @jadavsanjay @jarodortegaaraya @jigarkahar @joedolson @jonsurrell @joppuyo @josephscott @jsmansart @juanfra @kelvinballoo @khokansardar @khushi1501 @khushdoms @lakshyajeet @louischan @mabfahad @madhavishah01 @mai21 @manhar @manhphucofficial @manishxdp @maulikmakwana2008 @maxschmeling @mcsf @mdibrahimk48 @mindctrl @mirmpro @mokshasharmila13 @monzuralam @mosescursor @navi161 @nilambar @nimeshatxecurify @niravsherasiya7707 @noruzzaman @ocean90 @olmostblue @opurockey @ozgursar @palak678 @pavanpatil1 @pbiron @peterwilsoncc @phpbits @pmbaldha @poena @pooja1210 @poojapadamad @pratiklondhe @pratiknawkar94 @r1k0 @rahultank @ramonopoly @ravichudasama01 @rcorrales @rinkalpagdar @rishavdutta @rollybueno @ronya4927 @sabernhardt @sainathpoojary @sajib1223 @sajjad67 @sandeepdahiya @shailu25 @shekharnwagh @shibleemehdi @showravhasan @siliconforks @SirLouen @soyebsalar01 @sourabhjain @spiraltee @sukhendu2002 @suhan2411 @swissspidy @tobiasbg @tusharaddweb @tusharbharti @ugyensupport @valentingrenier @vgnavada @westonruter @wildworks @xwolf @youknowriad @yusufmudagal

Thank you, all of you. WordPress 7.0 is better because of your time and effort.

Get Involved — Help Test WordPress 7.1

The WordPress 7.1 cycle is already underway, and we’d love for you to join the testing effort. Testing is one of the most impactful ways to contribute to WordPress — and you don’t need to be a developer. If you can install WordPress, follow instructions, and describe what you see, you can be a test contributor.

Here’s how to get started:

1. Choose Your Setup

The quickest way is Test Core Tickets with Playground — test directly in your browser with zero setup. For applying .patch/.diff files or running test suites, follow the Set Up a Testing Environment guide to get a local Docker-based install running. To test the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, see the Test Gutenberg guide.

2. Find Something to Test

There are tickets and PRs waiting for testers right now:

Core Trac — Needs Testing — All open Core tickets needing testing, across all milestones
Gutenberg Issues — Needs Testing — Open GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ issues that need reproduction or verification
Gutenberg PRs — Needs Testing — Pull requests that need someone to verify the fix works

You can also check the Calls for Testing on the Test Team blog — these are focused, guided testing tasks with step-by-step instructions, perfect for new contributors.

3. Test and Report

Once you’ve found a ticket, there are two main types of testing you can do:

Issue Reproduction: Confirm that a reported bug is real by following the steps and describing your results. Use the Issue Reproduction template from the handbook.

Patch Testing: Apply a patch and verify it fixes the issue (or delivers the expected feature). Watch for regressions where the patch fixes one thing but breaks another. Use the Patch Testing template from the handbook.

Both templates include fields for your environment (OS, PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php version, WordPress version, browser) and space for your results. Just copy, fill in, and post as a comment on the ticket.

4. Help with Triage

If you’re comfortable navigating Trac, you can also help with ticket triage. When a ticket is tagged needs-testing, testers evaluate it and decide the next step. The Trac Keyword Triage Guide explains the four keywords testers manage (needs-testing, needs-test-info, dev-feedback, needs-refresh) and includes ready-to-use comment templates.

5. Get Recognized

Contributors who provide meaningful test contributions – reproduction reports, patch tests, unit tests, or documentation updates – earn the Test Contributor badge on their WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ profile. 
Learn more at Test Team Profile Badges.

Join the Community

#core-test on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ — The main hub for testing discussions, questions, and coordination
Test Team Handbook — Everything you need to know about testing WordPress
Contributor Day — Join a Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/ at a WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. near you, or participate remotely

Let’s keep making WordPress better, one test at a time. 🎉

Props to @ozgursar, @nikunj8866, @mosescursor for helping review this article and offering feedback.

#core-test, #make-wordpress-orgupdates, #wordpress-7-0

Month in Test: July 02, 2026

Hello and welcome to another edition of Month 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

  1. Calls for Testing 📣
  2. Test Handbook📘
    1. Merging of Test Handbook in Github
  3. Weekly Testing Roundup 🤠
    1. 1. WordPress Core Testing
      1. a. Patch Testing 🩹
      2. b. Bug Reproduction
      3. c. Test Team Issues
    2. 2. Gutenberg Testing
      1. a. Gutenberg Bug Reproduction Testing
      2. b. Gutenberg Patch Testing
  4. Profile Badge Awards 🎉
  5. Read/Watch/Listen 🔗
  6. Upcoming Meetings 🗓

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:

Test Handbook 📘

Merging of Test Handbook in GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/

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

Weekly Testing Roundup 🤠

Bi-Weekly update: Test Team Update

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 skills? Dive in to contribute, and gain coveted props 😎 for a coming release.

1. WordPress CoreCore Core 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 (13) 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:

b. Bug Reproduction

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 (135) have been reviewed and milestoned, and need testers to check the instructions and manually test if the issue is reproducible, then provide a bug reproduction report:

c. Test Team Issues

Here are the current activities being discussed in the Test Team Github:

  1. We need to review the Test Team Issues. If you have a possible solution, comment in the Issue or submit a PR.

2. GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ Testing

👋Want to contribute to WordPress/Gutenberg? If you have a bug or an idea, read the contributing guidelines before opening an issue. If you’re ready to tackle some open issues, we’ve collected some good first issues for you.

a. Gutenberg Bug Reproduction Testing

The following tickets (18) 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.

b. Gutenberg Patch Testing

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 (0) 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:

Profile Badge Awards 🎉

Congratulations to the recipients of the Test Contributor Badge 🎉

– Kindly find the Contribution Guidelines here

Read/Watch/Listen 🔗

  1. WordPress Ecosystem Announcements
  2. Test Team Announcements
    • Weekly Patch Testing Scrub: Second and Fourth Thursday of the Month at 15:00 UTC
    • Weekly Test Chat: Third Thursday of the Month at 15:00 UTC
    • Monthly Voice Test Chat: First Thursday of each month at 15:00 UTC
  3. Call for Testing

Upcoming Meetings 🗓

🚨There will be regular #core-test meetings. The schedule is being worked on and final schedule will be shared after finalizing the discussion

Current 2026 Schedule:

Interested in hosting a <test-scrub>? Test Team needs you! Check out Leading Bug Scrubs for details, or inquire in #core-test for more info.

props to @nikunj8866 for peer reviewing this post

#core-test, #fse-outreach-program, #gutenberg, #make-wordpress-orgupdates

WordPress 7.0 Updates & Testing – FAQ

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, pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party./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 Candidate A 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?

The final stable release of WordPress 7.0 is currently scheduled for May 20, 2026.


How can I know what is coming in WP 7.0 and how to test those features?

The following posts contain detailed information about new features, improvements, developer notes, and suggested testing areas for WordPress 7.0:

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 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 2 & Beta 3. Do I still need to test with RC5?

Yes — RCRelease Candidate A 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 Site A 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.


Should I test RC5 on a production website?

No. RC versions are intended only for testing.

Please use:

Do not test directly on live / production websites.


What should I test first?

Start with workflows you use most often.

Suggested areas:

  • BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor
  • Site editor
  • Publishing workflow
  • Media uploads
  • Theme compatibility
  • Plugin compatibility
  • Menus/widgets/navigation
  • Responsive/mobile behavior
  • AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)
  • 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 hooksHooks In 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 UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. controls
  • Failed saves/updates
  • JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com 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:

  1. Reproduce the issue multiple times
  2. Test with unnecessary plugins disabled
  3. Switch temporarily to a default theme
  4. 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

Then report the issue through:


What information should a bug report include?

A useful bug report should include:

  • WordPress version
  • PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php version
  • Browser/device
  • Active plugins/themes
  • Exact reproduction steps
  • Expected result
  • Actual result
  • Screenshots or screencasts (if available)

Clear reports help contributors verify and fix issues faster.


What if I find a security issue?

Please do not report security vulnerabilities publicly.

Security issues should be reported privately through:


How much testing is enough?

There is no minimum requirement. Even 15–30 minutes of focused testing is valuable.

Testing a few important workflows carefully is often more helpful than trying to test everything quickly.


Where can I follow WordPress 7.0 updates?

You can follow updates on:


What is a WordPress Release Party?

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.

Here are detailed instructions on how to contribute to a release party.

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❤️

#call-for-testing, #faq, #wp7-0

It’s time to test real-time collaboration!

Iteration issue: https://github.com/WordPress/gutenberg/issues/74549

Have you been waiting to collaborate in WordPress posts the way you do in Google Docs? Here’s your chance!

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

But before it can get there, RTC needs you! (And your friends!) Every part of this groundbreaking functionality, from front-end usability to literal php functions, plus database calls, APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. endpoints, and more, needs to run this first implementation through its paces.

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

Testing steps:

  • Install WordPress 7.0 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 on a server that somebody else can reach. 
  • This should probably be a new installation. maybe on a local network or on a staging server, or something in between—not a production server, but also not a local installLocal Install A local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer. on a single machine.
  • In the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party., navigate to Settings > Writing and toggle on “Enable real-time collaboration.
  • Open a post for editing. Start with a regular post, of course, but remember that pages are also posts, and custom post types are posts too! There are some exceptions, which you’ll find below. 
  • Invite a friend or colleague (or two or ten!) to edit the same post.
    • Consider joining a video call and sharing your screens so you can each see both experiences.
    • Or, collaborate with yourself! To do that, open your install in a separate tab and log in as someone else. See if you can edit as both people!
    • Another option: open your site on two machines on the same network.
  • If you have some, use real content—real text and images, other data sources and other media. See if you can use your usual workflows.

What to expect

  • Real-time collaboration only works when you’re editing posts in the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. It won’t function on other admin screens.
  • Classic post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes do not sync. Using these boxes still works, but your collaborators will not see updates in real time. They might even overwrite each other’s changes.
    • Without looking at the code, it’s not always obvious whether a post meta box is Classic (persisted using a save_post hook) or modern (integrated with the Gutenberg data store). Many plugins still use Classic post meta boxes.
  • Most blocks are compatible. Blocks are synced via their attributes, which means that most blocks support real-time collaboration by default. Some blocks might use local state when working with user input, which can result in issues during real-time collaboration.
  • Plugins that integrate with the block editor might have issues. Behavior with plugins is some of the most important feedback you can give. 
  • Collaborator cursors disappear in the Show Template view.
  • Collaborating on the same block can have issues. Please test it anyway, but expect quirkiness around cursor placement. Your feedback may well speed up the fix!
  • Syncing happens over HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. polling, so it’s not instant. It could feel laggy sometimes—please report this! As well, if it feels much smoother at some points than at others, please report that. Performance will directly affect how the community takes to RTC long-term.

What to notice

About overall functionality:

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

In real-life workflows, could you collaborate:

  • On custom blocks?
  • Inside a plugin’s UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.?
  • In the site editor?
  • On a large document?
  • If you added more than one user?

How did RTC do on accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)? Did it work:

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

Thank you!

Please report your findings to the fine folks at #feature-realtime-collaboration on Make SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/, or directly to the authors of this post. If you’re comfortable with GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/, the best place to report would be in comments on the tracking issue, #52593.

One more thing: RTC is getting its own table.

That hasn’t merged yet, but if you want to follow its progress, start with the discussion on the ticket at https://core.trac.wordpress.org/ticket/64696#comment:44 and happy testing!

Props to @ankit-k-gupta, @maxschmeling, @czarate, and @annezazu for peer review and collaboration.

#7-0, #core-test, #gutenberg