Highlighted Posts

Categorize a post as Highlight to add it to this section.

X-post: Test Team Update: 23 October, 2026

X-post from +make.wordpress.org/updates: Test Team Update: 23 October, 2026

X-post: WordPress Contributor Toolkit 2.0: A redesigned app, in your language

X-post from +make.wordpress.org/core: WordPress Contributor Toolkit 2.0: A redesigned app, in your language

Help Test WordPress 7.2

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

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

Early testing is critical.

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

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

Got a few minutes? A few hours? Every bit of testing makes a big difference — possibly, the difference between a major feature landing in 7.2 or getting punted to a future cycle!

Stay informed!

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

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

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

Thank you!

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

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

🧊 Testing Tips

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

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

Or if you feel compelled, push WordPress to its limits. Try to break things. Have multiple editors in wp-admin at once, upload unusual media formats, paste complex layouts, step outside standard practices and use WordPress in unexpected ways.

Notice something unexpected? Run into a bug? Is a feature not behaving the way you thought it would? Please consider reporting it directly to WordPress Trac (for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. bugs) or to the Gutenberg repository (for editor issues).

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

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

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

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

How to test WordPress Beta Versions

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

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

WP-Playground

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

A Local Site on your computer

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

How to set up your site:

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

Follow this guide for more detailed instructions.

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

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

Steps:

  1. Create a local WordPress site however you like to do it. Wait for the notification that your site is ready.
  2. Open your terminal and navigate to the root directory of your WordPress installation.
  3. Run the following command to update to the latest beta version:
    wp core update --version=7.2-beta1
    Or
    wp core update --version=7.2-RC1
    (Replace the version number as needed, such as –version=7.2-beta2.)

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

A Staging Site on your host

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

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

Testing Patches

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

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

Follow these instructions to set it up.

Testing tickets in the browser

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

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

General Testing Checklist

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

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

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

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

Key Features to Test

Security

Secrets API & Credential Storage

WordPress previously lacked a standard, first-class way to store private keys and API credentials, leaving plugins to store credentials as plain-text options. WordPress 7.2 introduces the Secrets API along with WP-CLI support to securely handle credentials with native libsodium encryption.

ðŸ“Ģ Dedicated Proposal: Proposal: A Secrets API for WordPress 7.2

Testing Steps:

  1. Navigate to Tools ➜ Site Health to verify the Secrets API tests under the Status tab and review encryption details under the Info tab.
  2. Test registering and retrieving credentials using the Secrets API helper functions in test code or via WP-CLI.
  3. Confirm that credentials stored via the Secrets API are encrypted/protected in the database and never exposed in plain text.
  4. Verify that secret values are omitted or redacted from REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/ responses, debug logs, Site Health info, and XML export files.
  5. Test invalid credential calls to ensure graceful failure handling without fatal errors.

Expected:
Secrets are safely registered, stored securely, and retrievable only through authorized API methods without leaking into logs or exports.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here under the Security component. Follow Trac #66187 for more details.

HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. API Processing Hardening

WordPress 7.2 continues to harden how WordPress parses and processes HTML tags and tokens, ensuring markup manipulation throughout Core and plugins is safer, faster, and standard-compliant without regular expression vulnerabilities.

Testing Steps

  1. Test rendering posts and blocks with complex, nested HTML and custom tags.
  2. Verify that self-closing tags, script tags, and custom attributes parse without truncation or broken layout.
  3. Check for any regression in post content formatting or shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. expansions.

Expected:

HTML is parsed and processed cleanly without layout breakage, performance penalty, or security vulnerabilities.

Testing Instructions:

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

Collaboration & Notes

Notes: Collaboration, Filtering & Canvas Enhancements

The block collaboration and Notes feature receives major workflow, accessibility, and canvas enhancements in WordPress 7.2:

  • Floating Canvas & Dual Sidebars: You can now open both the block Settings sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. and the Notes panel simultaneously side-by-side without one closing the other.
  • All Notes Filtering: The dedicated All Notes sidebar now supports granular filtering to quickly find open threads and review comments.
  • Minimizing & Managing Notes: Added intuitive controls to hide, minimize, and expand individual note cards directly on the canvas to reduce visual clutter while writing.
  • Emoji Reactions & Persistent Toolbar: Quick emoji reactions (👍, âĪïļ, 🚀) for fast feedback loops, with a persistent Add Note button remaining accessible in the block toolbar.
  • Color & Contrast Hardening: Refined colors, border indicators, and contrast ratios for improved accessibility across light and dark editor themes.

Testing Steps:

  1. Open any post or page with multiple blocks in the editor.
  2. Select a block, click the Add Note button in the block toolbar, and leave a test comment.
  3. Open the Settings panel (gear icon) on the right:
    • Verify that the canvas floats cleanly and both the Settings sidebar and Notes panel can stay open at the same time.
  4. On an active note card, test the new controls:
    • Click the minimize / expand control to collapse and expand note threads.
    • Add an emoji reaction (👍, âĪïļ) and verify reaction counts increment smoothly.
  5. Open the All Notes panel from the top headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.:
    • Test the filtering options to sort and filterFilter Filters 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. active vs. resolved notes.
  6. Verify that note badge colors and text contrast remain legible across different admin color schemes.

Expected: Notes provide a smooth, unobtrusive collaboration experience with simultaneous sidebar support, fast filtering, collapsible cards, and instant emoji reactions.

Testing Instructions:

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

Admin & Extensibility

DataForms: Post Inspector Replacement

In WordPress 7.2, the traditional post settings inspector (Status, Visibility, Publish Date, Author, Featured ImageFeatured image A 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., ExcerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox., Template, etc.) is being migrated to a modern, extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. DataForm. This marks a massive leap forward in unifying admin 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. components across WordPress.

ðŸ“Ģ Dedicated Call for Testing post: Call for Testing: DataForm Editor Inspector

Testing Steps

  1. Open any post or page in the block editor.
  2. Open the Settings sidebar (right-hand panel) and ensure the Post / Page tab is active.
  3. Inspect each field rendered inside the new DataForm:
    • Status & Visibility: Toggle between Public, Private, and Password Protected.
    • Publish Date & Time: Change date and schedule.
    • Author: Switch author via the selector.
    • Featured Image: Set, replace, and remove a featured image.
    • Excerpt: Enter custom excerpt text.
    • Template: Switch templates.
  4. Save/update the post and refresh the browser: confirm all values persist accurately.
  5. Check visual hierarchy (Issue #80360) and bulk action discoverability (Issue #80408).
  6. Resize the sidebar and browser window to confirm fields wrap gracefully without overlapping.

Expected:

The DataForm-based post inspector provides complete feature parity with the previous post settings sidebar, with improved keyboard accessibility and clear extensibility foundations.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow DataViews & DataForm in WordPress 7.2 (#81228) for more details.

SVG Icons in Admin Bar & Menu (Replacing Dashicons)

Dashicons font icons in the top admin bar and the left-hand admin menu have been swapped for crisp, scalable SVG icons. This renders icons more reliably, improves performance, and enables proper accessibility announcements for screen readers.

ðŸ“Ģ Dedicated Announcement: Replacing Dashicons in the Admin Bar and Menu

Testing Steps

  1. Navigate across wp-admin screens and inspect the top admin bar and the side navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site..
  2. Zoom your browser to 200%, 300%, and 400%: confirm that icons remain pin-sharp without icon-font anti-aliasing glitches.
  3. Go to Users → Profile and test different Admin Color Schemes (Default, Light, Modern, Blue, Coffee, Ectoplasm, Midnight, Ocean, Sunrise): verify that all SVG icons adapt their colors smoothly.
  4. Test with a screen reader: confirm SVG icons do not announce random private-use Unicode characters, but rather announce proper accessible labels or are appropriately hidden with aria-hidden=”true”.

Expected:

Admin bar and menu icons render sharply at all zoom levels, adapt cleanly to all admin color palettes, and provide proper accessibility attributes.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here. Follow Gutenberg Issue #82723 and report any alignment or visual regressions.

Blocks & APIs

Keyword Search for Icon Block

The Icon block now supports rich synonym keywords, making it easier to discover the right icon without guessing exact icon names.

Testing Steps

  1. Insert the Icon block into a post.
  2. In the icon picker search input, type synonyms such as “mail” or “letter” (to find the envelope icon); “plus” (to find the + icon) etc.
  3. Confirm relevant icons appear in the search results matching your keyword synonyms.

Expected:

Icon search returns intuitive results based on everyday vocabulary and aliases.

Testing Instructions:

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

Building and editing navigation menus becomes noticeably faster and more intuitive in WordPress 7.2 with major upgrades to link searching and inserter relevance:

  • Banded Search Results: Link searching now prioritizes content types and returns categorized results, making it effortless to find specific pages, posts, or archive links.
  • Navigation Blocks in Search: In addition to URLs, searching directly surfaces specialized blocks like the Home link block, allowing creators to assemble complete navigation bars in fewer clicks.

Testing Steps:

  1. Open the Site Editor or post editor and select a Navigation block.
  2. Click the + (Add block / link) inserter inside the Navigation block.
  3. Type keywords into the link search input (e.g., search for a page title, post name, or categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging.):
    • Confirm that results are banded and clearly categorized by content type.
    • Type “Home” and verify that the dedicated Home link block appears directly in the search results.
  4. Select a page or block to insert it:
    • Verify that the item adds cleanly to your navigation menu with the correct label and link.
  5. Test pasting an external URL (e.g., https://wordpress.org):
    • Confirm that external link creation works smoothly without keyboard focus glitches.

Expected:
Navigation search provides banded, prioritized results and allows inserting both content links and navigation blocks seamlessly within the search interface.

Testing Instructions:
If you encounter any issues or unexpected behaviour while testing, please log them here. Follow Gutenberg Issue #77069 for more details.

Interactivity API (data-wp-html & Router Navigation)

The Interactivity API provides a standard way to build reactive frontend experiences. WordPress 7.2 introduces the data-wp-html directive to safely render reactive markup from state stores, alongside router navigation detection improvements.

Testing Steps

  1. Test interactive blocks or test plugins utilizing data-wp-html.
  2. Confirm trusted markup updates reactively as store state changes.
  3. Test client-side navigation transitions on interactive regions: verify that route changes trigger observers without page reload regressions.

Expected:

Reactive HTML strings render safely without XSS vulnerabilities, and router state transitions execute predictably.

Testing Instructions:

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

Design & Global Styles

Design Tool Additions & Expanded Block Supports

WordPress 7.2 continues the multi-release initiative to unify and expand design tools across all core blocks. Over 70+ block support enhancements have merged, bringing advanced styling controls to blocks that previously lacked them:

  • Text Gradients: Added native text gradient support with background-clip and an intuitive gradient UI picker for supported typography blocks.
  • Expanded Block Supports: Broadened controls for Dimensions (width/height), Drop Shadow, Background images, Typography, Spacing, and Borders across dozens of core blocks.

Testing Steps:

  1. Open the post editor or Site Editor and insert various core blocks (e.g., Heading, Paragraph, Group, Buttons, Columns).
  2. Open the block settings sidebar (right inspector):
    • Under Typography / Color, test applying a Text Gradient to headings or text blocks.
    • Under Dimensions & Spacing, verify that width, height, margin, and padding controls function smoothly without layout breaks.
    • Test applying custom Borders and Drop Shadows to supported container and content blocks.
  3. Check the frontend of the site:
    • Verify that text gradients render cleanly across modern browsers (Chrome, Safari, Firefox).
    • Confirm that block styles and spacing scale properly across desktop and mobile screens.

Expected:
Core blocks support consistent design controls (text gradients, spacing, borders, shadows) and render uniformly on both editor and frontend without CSS conflicts.

Testing Instructions:
If you encounter any issues or unexpected behaviour while testing, please log them here. Follow Gutenberg Issue #76525 for more details.

Filtering Customized Blocks in Global Styles

When designing a site, it’s easy to lose track of which specific blocks have custom styles applied. WordPress 7.2 introduces a dedicated filter in the Global Styles Blocks list, allowing creators to quickly filter and view only the blocks that have custom styling overrides:

  • Customized Filter View: Filter the Global Styles block list to display only modified blocks, removing the need to click through dozens of blocks to find your customizations.

Testing Steps:

  1. Open the Site Editor and click Styles (the half-black/half-white circle icon).
  2. Navigate to Blocks.
  3. Select a couple of blocks (e.g., Heading, Buttons) and apply custom styling (such as custom colors or typography).
  4. Return to the main Styles → Blocks list and locate the filter control at the top.
  5. Switch the filter to Customized:
    • Verify that the block list instantly narrows down to show only the blocks you modified.
    • Confirm that uncustomized default blocks are hidden from the list.
  6. Switch the filter back to All to verify the full list of blocks returns.

Expected:
The Customized filter cleanly isolates modified blocks in Global Styles, making it fast and effortless to review and manage design customizations across the site.

Testing Instructions:
If you encounter any issues or unexpected behaviour while testing, please log them here. Follow Gutenberg PR #84657 for more details.

WordPress 7.2 expands creative visual styling for galleries by allowing creators to apply duotone color filters to an entire Gallery block at once:

  • Uniform Gallery Tinting: Apply a single duotone filter to the parent Gallery block, instantly tinting all nested images simultaneously without having to configure each image individually.
  • Gallery Sorting Controls: Easily reorder and sort gallery images directly within the block controls.

Testing Steps:

  1. Open a post or page in the editor and insert a Gallery block containing multiple images.
  2. In the block toolbar or block settings sidebar, select the Duotone filter control.
  3. Choose a duotone preset (such as Sepia or Blue/Orange):
    • Verify that every image inside the gallery immediately inherits the duotone tint.
  4. Test adding a new image to the gallery:
    • Verify that the newly added image automatically adopts the gallery’s duotone filter.
  5. Check the frontend of the site:
    • Confirm that all images render cleanly with the applied duotone filter across desktop and mobile screens.

Expected:
Duotone filters apply uniformly across all nested gallery images, providing instant visual consistency without per-image manual configuration.

Testing Instructions:

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

Site-Wide Duotone Palettes in Global Styles

Global Styles in WordPress 7.2 expands visual palette customization by introducing a dedicated Duotone editing tab directly inside the Site Editor’s color settings:

  • Custom Duotone Presets: Under Global Styles (Styles → Colors → Palette), you can now create custom duotone pairings (shadows & highlights) and edit existing default presets alongside Solid colors and Gradients.
  • Theme & Site-Wide Integration: Custom duotone presets defined in Global Styles become instantly available across all supported media blocks (Images, Galleries, Covers).

Testing Steps:

  1. Open the Site Editor and navigate to Styles → Colors → Palette.
  2. Click the new Duotone tab (located next to Solid and Gradient).
  3. Test editing an existing default duotone preset or click to add a custom duotone pairing.
  4. Select custom colors for both the shadows (dark tones) and highlights (light tones).
  5. Save Global Styles and open a post or page.
  6. Insert an Image block or Cover block and verify that your custom duotone preset appears as a selectable option in the Duotone picker.

Expected:
Creators can define and manage custom site-wide duotone palettes in Global Styles, making custom branding filters available across all supported media blocks.

Testing Instructions:

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

Text Shadow Support in Typography Controls

A long-requested styling capability arrives in WordPress 7.2: native Text Shadow support. Creators can now add subtle depth, glowing effects, and retro contrast to text directly from the editor without writing custom CSS:

  • Typography Shadow UI: Access text shadow controls and presets directly inside the Typography panel in both Global Styles and individual block inspectors.
  • Theme & Preset Integration: Supports default shadow presets as well as custom offsets, blur radius, and color pairings.

Testing Steps:

  1. Open the Site Editor and click Styles → Typography.
  2. Select an element (such as Headings or Text) and look for the new Shadow control in the Typography section (click the three-dot options menu if the control is hidden).
  3. Select an existing shadow preset or configure a custom text shadow (adjusting color, blur, and X/Y offset).
  4. Save Global Styles, then open a post or page in the editor.
  5. Insert a Heading block and test applying a local text shadow override directly from the block’s Typography inspector.
  6. View the frontend of the site:
    • Verify that text shadows render cleanly across light and dark backgrounds.
    • Confirm that text remains crisp and legible on high-resolution displays and mobile devices.

Expected:
Text shadow controls apply smoothly to typography across core blocks, rendering standard-compliant text shadows in both the editor and frontend.

Testing Instructions:
If you encounter any issues or unexpected behaviour while testing, please log them here. Follow Gutenberg PR #79584 for more details.

Form Elements in Global Styles

WordPress 7.2 brings the ability to style common form elements (Buttons, Text Inputs, Select dropdowns, and Labels) directly from the Global Styles interface without touching CSS or manually editing theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML..

Testing Steps

  1. Open the Site Editor and click Styles (the half-black/half-white circle icon).
  2. Navigate to Blocks / Elements → Form Elements.
  3. Customize styling for Text Inputs (border color, radius, background, padding), Select Elements (typography, border), and Labels (font family, weight, letter spacing, text color).
  4. Save the global styles.
  5. View frontend pages containing forms (e.g. Comment form, Search block, or contact forms).
  6. Verify that your customized form styles apply consistently across all form fields.

Expected:

Form elements reflect global styles predictably across all standard form controls on the website.

Testing Instructions:

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

Display Inherited Styles in Block Inspector

Previously, block inspector controls didn’t indicate values inherited from Global Styles, leaving control fields empty when no local styles were applied. In WordPress 7.2, inspector controls clearly display the inherited values from Global Styles (including typography, colors, and element styles) directly within the block settings.

Testing Steps:

  1. Open the Site Editor and customize a global setting (e.g., set a global typography font size or text color under Styles).
  2. Select or insert a block that inherits these global settings (e.g., a Paragraph or Heading block).
  3. Open the block settings sidebar (right inspector):
    • Confirm that the inspector controls clearly display the inherited global values instead of remaining empty.
  4. Apply a custom local override to the block (e.g., select a custom text color).
    • Verify that the block reflects the local override cleanly on the canvas.
  5. Clear or reset the custom local style:
    • Verify that the control seamlessly reverts back to showing the inherited global style value.

Expected:
Inspector controls transparently display inherited Global Styles values across blocks, making it immediately clear what styles are active without digging into global style menus.

Testing Instructions:

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

Custom states allow users to style the “active” or currently viewed page link directly from the editor — ensuring the active page in a navigation menu stands out clearly to visitors.

Testing Steps:

  1. In the Site Editor or post editor, insert a Navigation block with multiple page links.
  2. Select a Navigation Link or open Styles → Blocks → Navigation Link.
  3. In the block inspector, access the state selector and switch to the -current (Active) state.
  4. Apply custom styling (e.g., a distinct text color, background pill, or font weight).
  5. Save and view the menu on the frontend:
    • Navigate to the linked page and confirm that the active page’s link displays your custom -current styling.
    • Switch between pages to ensure the active styling updates dynamically to reflect the current URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org.

Expected:
Active navigation links receive dedicated styling that renders reliably whenever the targeted item matches the currently viewed page.

Testing Instructions:

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

Responsive Style States & Block Controls

Following the introduction of responsive styling in 7.1, WordPress 7.2 expands responsive controls with a public API for third-party blocks and adds granular responsive controls across core blocks:

Gallery Block Responsive Controls: You can now configure gallery column counts, aspect ratio, and crop-to-fit settings per viewport breakpoint (e.g., 4 columns on desktop, 2 on tablet, 1 on mobile).

Position & Custom States: Supports setting position controls and custom CSS rules targeted to specific viewport states.

Testing Steps:

  • Insert a Gallery block with multiple images and open the Settings sidebar.
  • In the editor top bar, switch the device preview to Tablet or Mobile.
  • Adjust the Columns slider, toggle Crop images, or adjust the Aspect Ratio specifically for this mobile/tablet viewport.
  • Switch back to Desktop preview mode: Verify that your desktop gallery layout remains untouched, while mobile/tablet displays your custom column and crop layout.
  • In the Advanced panel, test adding custom CSS rules for specific responsive states.
  • Check the frontend of the site using browser DevTools (responsive mode) to confirm the styles apply seamlessly at defined breakpoints.

Expected:

Responsive controls apply cleanly per breakpoint without layout bleed, and gallery settings adapt dynamically between desktop, tablet, and mobile views.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them under the Editor component. Follow 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/ Issue #80388 for more details.

Default Theme: Ipsum

Introducing Ipsum, the new default theme

WordPress 7.2 bundles a brand-new default block theme called Ipsum — an intentionally minimal blank canvas blog theme designed to give creators room for creativity.

ðŸ“Ģ Dedicated Announcement: Introducing Ipsum, the new default theme

Testing Steps

  1. Go to Appearance → Themes and activate Ipsum.
  2. Open the Site Editor:
    • Inspect the bundled Style Variations: switch between colorways and typography pairings.
    • Test bundled Block Patterns (Header patterns, Post lists, Footers, Callouts).
    • Check the Templates: Index, Single Post, Page, 404, and Archive.
  3. Add a variety of content (images, quotes, tables, description lists) and check frontend display.
  4. Verify responsiveness across desktop, tablet, and mobile screens.
  5. Check compatibility across 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 versions (PHP 7.4 through PHP 8.4+).

Expected:

Ipsum serves as a clean, performant, accessible blank canvas with versatile style variations and robust pattern layouts.

Testing Instructions:

If you encounter any issues or unexpected behaviour while testing, please log them here.

Media & Performance

Redesigned Media Inserter & Dynamic Galleries

The media inserter receives a major redesign tailored for sites with large media libraries, alongside dynamic gallery enhancements and sorting options for static galleries.

Testing Steps

  1. On a site with hundreds of uploaded images, open the Media Inserter in the editor.
  2. Test browsing, searching, and filtering images: confirm performance remains fast and pagination/infinite scroll is seamless.
  3. Insert a Gallery block and choose “Use attached images” (Dynamic Gallery): verify it automatically displays images attached to the current post.
  4. For a standard static gallery, test the new sorting controls: confirm you can reorder images by date, title, or custom drag-and-drop order.

Expected:

Media browsing is snappy even on massive media libraries, and galleries provide intuitive dynamic sources and sorting controls.

Testing Instructions:

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

Media Editor Modal: Crop Lineage Tracking

Following its debut in 7.1, the Media Editor Modal now tracks formal lineage between cropped image attachments and their original master images, preventing orphaned, cluttering attachments in your media library over time.

Testing Steps

  1. Insert an Image block and open the Crop tool (Media Editor Modal).
  2. Perform a crop or rotation and save.
  3. Inspect Media → Library: verify that the cropped derivative is clearly linked to its original master image.
  4. Re-open the Media Editor on the cropped image: confirm you can restore or re-adjust the crop based on the original asset.

Expected:

Cropped derivatives maintain bidirectional lineage with their parent originals, preventing library bloat.

Testing Instructions:

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

Client-Side Media Processing Iteration

Client-side media processing via WebAssembly (wasm-vips) receives major expansions in WordPress 7.2, moving beyond the block editor into the broader media pipeline:

  • Animated Image Sub-Sizes (Fixes 2014 Bug): Resolves a 12-year-old limitation (TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. #28474 / Gutenberg PR #80385). When uploading animated GIFs or animated WebP files, all generated sub-sizes (including cropped thumbnail sizes) now retain full animation by default instead of collapsing into static single frames.
  • Expanded to Media Library & Modal: Extends client-side upload handling beyond the block canvas into the native Media Library (Media → Add New) and the media modal (PR #12585).

Testing Steps:

  1. In a Chromium browser, upload an animated GIF or animated WebP file in the block editor or directly via Media → Add New.
  2. Insert the image into a post and test selecting different image sub-sizes (Thumbnail, Medium, Large):
    • Verify that every resized derivative continues to animate smoothly on both editor and frontend.
  3. Test uploading modern image formats in the media library (AVIF, WebP, HEIC) to confirm sub-sizes generate locally in the browser before upload.
  4. Test in a non Chromium browser (Safari/Firefox) or simulate low memory:
    • Verify that WordPress gracefully falls back to traditional server-side media processing without upload failure.

Expected: Client-side processing integrates seamlessly into both the editor (including the media library tab) and Media Library uploads and preserves animation across resized derivatives.

Testing Instructions: If you encounter any issues or unexpected behaviour while testing, please log them under the Media component. Follow PR #12585 and Gutenberg PR #80385 for more details.

Accessibility & Quality of Life

Toggle to Disable MetaboxMetabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way. Rearranging

To prevent accidental visual clutter and unintentional dragging on mobile and touchscreen devices, WordPress 7.2 introduces an option to turn off metabox rearranging on classic edit screens.

Testing Steps

  1. Open a screen with metaboxes (such as the classic post editor or dashboard).
  2. Open Screen Options at the top right of the screen.
  3. Locate the new setting to “Disable metabox rearranging”.
  4. Check the option: verify that drag handles are disabled and metaboxes cannot be accidentally moved or dropped into awkward layout columns.
  5. Uncheck the option: verify drag-and-drop reordering functionality returns immediately.

Expected:

Users on touchscreens and mobile devices can lock metaboxes in place to prevent accidental layout shifts.

Testing Instructions:

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

Where to Report Feedback

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

Choose any of these options:

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

Include as much detail as you can in your report:

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

Changelog

1.0.0 – Initial Post for WordPress 7.2 Beta 1

Props to @jns141191 and @r1k0 for authoring and co-leading the WordPress 7.2 Call for Testing documentation and testing guides, and to @annezazu, @adamsilverstein, and @huzaifaalmesbah for the pre-publish review of this post.

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

Test Chat Summary: 15th October, 2026

On Thursday, 15th October 2026, 03:00 PM UTC, <test-chat> started in  #core-test facilitated by @huzaifaalmesbah. The agenda can be found here.

1. Attendance

In attendance was:
@ozgursar @faisalahammad @andrewssanya @mosescursor @abdullah17 @noruzzaman @sirlouen @softglaze @iqbal1hossain (async) @nikunj8866 (async)

2. Volunteer

This week’s Note-taker was @huzaifaalmesbah

3. Test Team Discussions

  • Contributor Toolkit Documentation (Issue #189): Voting concluded with unanimous consensus for Option 1 (a dedicated new guide page under get-setup-for-testing/). The team opened a call for contributors to help draft the page covering bug reproduction and patch testing with the desktop app.
  • TestFlow Extension Proposal (Issue #184): The proposal was scoped down to adding 3 separate ticket textareas by difficulty (Beginner, Intermediate, Expert) into the session 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.. 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/ webhook automation was excluded, and session recap export is deferred until a regular blog recap format is defined. The issue is marked needs-pr. @softglaze volunteered to work on the PR against the TestFlow repository, with @ozgursar available to assist.

4. Open Floor

  • Handbook Pull Requests #190 and #191:
    • PR #190: Shows 0 changed files after a recent trunk merge; intended changes need to be re-pushed.
    • PR #191: Needs a minor review comment addressed from @sirlouen.
    • @sirlouen confirmed he is available to verify the review once changes are pushed. The team agreed to give @jenish1234 time to update both branches before stepping in to help finish them.
  • CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. PR Testing Workflow:
    • @ravipatel requested testing for three new wordpress-develop pull requests (PR 14209, PR 14273, PR 14280).
    • @huzaifaalmesbah clarified that new PRs typically need review from a Core committer or component maintainer first, who then add the needs-testing TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. keyword when ready for broader testing. Interested team members were invited to test and share results.

5. Announcements

WordPress Ecosystem Announcements

Test Team Announcements

Call for Testing

Team Chat Agenda: 15th October, 2026

Here is the agenda for the upcoming Test Team Chat scheduled for Thursday, 15 October 2026, 03:00 PM UTC, which is held in the #core-test Slack channel. Lurkers welcome!

Agenda

Leave a Comment

  • Do you have something to propose for the agenda?
  • Can’t make the meeting, but have a question for the Test Team?

If any of the above apply, please leave a comment below.

#test-chat-agenda

X-post: Test Team Update: 09 October, 2026

X-post from +make.wordpress.org/updates: Test Team Update: 09 October, 2026

Test Chat Summary: October 1st, 2026

🎧 Huddle Notes: 10/1/26 in #core-test.
AI took notes for this huddle from 1:01:19 AM – 1:40:59 AM GMT+10. The test team reviewed three agenda items: WordPress Contributor Toolkit documentation proposal, two pull requests requiring updates/merging, and discussed post-review workflow limitations

Attendees

@r1k0, @jns141191, @ozgursar, @abdullah17, @iqbal1hossain, @rakib03029

Summary

WordPress Contributor Toolkit Documentation

@r1k0 introduced a proposal by Huaifa to add documentation for the Contributor Toolkit desktop app developed by Juanma. [7:04]

@ozgursar and @jns141191 agreed that a dedicated new page would be better than adding to existing documentation, allowing more screenshots and details without distraction. [11:38][12:16]

@r1k0 will post a poll after the meeting for team-wide feedback before creating the new page. [12:46]

Pull Request #190: 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/ Guide

@ozgursar‘s noted files changed shows 0 despite previous suggestions submitted, indicating a commit error. [14:08][14:24]

@r1k0 and @ozgursar‘sspeculated the author forgot to push changes to origin, preventing 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/ from recognizing updates. [14:55][16:07]

@r1k0 will pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” the author to update the pull request. [16:44]

Pull Request #183: Minor Edits Ready to Merge

@ozgursar confirmed the pull request looks good with two approvals and no reason to wait for author response. [21:53][22:12]

@r1k0 noted a maintainer suggested minor wording changes that can be applied directly without author involvement. [22:23]

@r1k0 will apply suggested changes, commit, notify the team, and merge by end of day. [23:22]

Soft Glaze Proposal: Awaiting Author Response

@ozgursar reported the author has not replied to comments from @ozgursar and @huzaifaalmesbah suggesting implementation steps. [24:23][24:38]

@r1k0 will ping the author again to revive the issue and encourage a pull request. [24:58]

Open Floor

Post Review Workflow Limitations

@jns141191 asked if test handbook posts can assign user roles for direct review instead of messaging channels.

@r1k0 confirmed no native role-assignment system exists; posts on Make Test site require site access to review. [30:51][32:30]

@iqbal1hossain suggested using Google Docs or Google Sheets as a workaround to share drafts for external review without site access. [33:26][33:43]

Announcements and Ecosystem Updates

  • WordPress ecosystem announcements including 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/ 24.1, Contributor Toolkit 1.2, and WordPress 7.1.1 release schedule.
  • Active calls for testing including DataForm editor inspector, community groups, and WordPress 7.1.1 patch testing.

Action items

@r1k0 will post a poll for team feedback on creating a dedicated Contributor Toolkit documentation page. [12:46]

@r1k0 will ping the author of PR #190 to push missing changes to origin. [16:44]

@r1k0 will apply suggested wording changes to PR #183, commit, notify team, and merge by end of day. [23:22]

@r1k0 will ping the soft glaze proposal author to revive the issue and encourage a pull request. [24:58]

Files and media

#test-chat-summary

Month in Test: October 05, 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 (19) 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 (128) 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 🎉

@softglaze, @369work, @habiburdev, @ekamran, @dhavalkapadane, @jdab, @rahultank, @chinmoy709, @arifulislam1, @ahsannayem

– 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 @huzaifaalmesbah for peer reviewing this post

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

Test Scrub Schedule for WordPress 7.2

As most of you already know, WordPress 7.2 is set to be the final major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality. of 2026, currently targeted for December 8, 2026. As we gear up for this key milestone, our Test team will be switching things up a little.

Starting with our next weekly Patch Testing Session, we’ll be running a Test Scrub dedicated to WP 7.2 in place of the usual Future Milestone Tickets session. These scrubs will center on tickets and issues tied to the 7.2 milestone specifically. It’s a solid way to get hands-on with a major release and help shape what ships.

Test Scrub in Place of Patch Testing Sessions

From our next scheduled session onward, Test Scrubs will run on the 2nd and 4th Thursday of each month at 3:00 PM UTC. These sessions will focus specifically on WordPress 7.2 milestone tickets.

Where Will It Happen?

Each Test Scrub takes place in the #core-test channel on the Make WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/, at the same time as our regular weekly Test team meetings. If any additional release-focused scrubs get scheduled, they’ll be announced in the same channel as well and added to the meetings calendar.

What Tickets Will We Focus On?

The main focus will be tickets tagged Has Patch or Needs Testing against the 7.2 milestone. You can pull these up directly from the 7.2 report on Trac. As the release progresses through 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. and RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge., we’ll also shift attention toward key features and regressions that need dedicated testing.

Interested in Leading a Test Scrub?

Did you know anyone can lead a Test Scrub, any time? That includes you.

If you’d like to run one, reach out in the #core-test Slack channel with:

  • The day and time you have in mind
  • The report or tickets you’d like to focus on (a specific TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. report, a feature area, or a Beta/RC build, for example)

If your scrub is specifically focused on WordPress 7.2, even better — let us know and we’ll add it to the schedule so the rest of the team knows to join in. Leading a scrub is one of the most direct ways to contribute.

Let’s Contribute Together

This is a great opportunity to get involved with the WordPress 7.2 release, learn more about how the release process works, and help ensure the overall quality and stability of WordPress. Every contribution counts, so come join us for the Test Scrub sessions and be part of this release.

Thank You âĪïļ

Thanks to everyone who contributes time, testing, feedback, and expertise — community testing is a key part of what makes every WordPress release successful.

Let’s work together to make WordPress 7.2 a smooth and high-quality release.

Props to @r1k0, @huzaifaalmesbah, @noruzzaman for pre-publish review.

Test Team Chat Agenda: 1st October, 2026

Here is the agenda for the upcoming Test Team Voice Chat scheduled for Thursday, 01 October at 18:00 GMT+3, which is held in the #core-test Slack channel. Lurkers welcome!

Agenda

Leave a Comment

  • Do you have something to propose for the agenda?
  • Can’t make the meeting, but have a question for the Test Team?

If any of the above apply, please leave a comment below.

#agenda, #test-chat-agenda