Skip toolbar
WordPress.org

Make WordPress

Noruzzaman Test ·

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.

Random Content Redirects

WordPress 7.2 adds built-in random content redirects: visiting /random/ on any site takes visitors to a randomly selected published post — perfect for “Surprise me” links, content discovery, and rediscovering older posts.

  • Random URLs for the whole site and archives: /random/ works site-wide, for categories, tags, authors, and post type archives (e.g. /random/categoryCategory The ‘category’ taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging./news/), plus search results with ? random.
  • Configurable Random base: A new “Random base” field on the Permalinks screen lets you rename /random/ (it is also translatable).
  • Developer controls: Post types opt in with the new randomable argument (enabled by default for public post types with an archive), and the feature can be disabled with the wp_enable_random_content_redirect filter.

Testing Steps

  • Make sure pretty permalinks are enabled and publish a few posts, with some in the same category.
  • Go to Settings Permalinks and confirm the new Random base field in the Optional section.
  • Visit /random/ several times: confirm each visit redirects to a published post and that the post changes between visits.
  • Visit /random/category/{category-slug}/ and /random/author/{username}/: confirm you only land on posts from that category or author.
  • Visit /?s={keyword}&random: confirm you land on a random post from the search results.
  • Visit a random URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org with no matching content (e.g. /random/category/does-not-exist/): confirm a 404 is returned rather than a redirect.
  • Change the Random base (e.g. to surprise) and save: confirm /surprise/ now redirects randomly, then restore the default.

Expected:

Random URLs return a temporary (302) redirect to a random published post that matches the requested archive or search, include noindex headers, and return a 404 when nothing matches.

Testing Instructions:

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

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 category):
    • 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.

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

Courtney Robertson

Tested on 7.2-beta4: local Docker with PHP 8.3, Chromium 156, Firefox 157 and WebKit 27.2 through Playwright, a 7.1.4 site as the control, and a 7.1.4 site with five plugins upgraded in place.

Worked as described: Notes (reply, resolve, reactions, filter), HTML API hardening, Icon block keyword search, text gradient and the other design tools, the Customized filter in Global Styles, gallery and site-wide duotone, text shadow, form element styles including the new label element, responsive styles, the Media inserter and dynamic galleries (capped at 100 images), crop lineage in the Media editor, the DataForm inspector, and the general checklist on the upgraded site. Client-side media in Firefox falls back to the server path, as expected.

Three things to flag:

Also found while testing: the button-only Search block has no accessible name until JavaScript runs, reported in Search block (button only) loses aria-label and tabindex after directive processing (#86314).

AI assistance: Yes. Tool: Claude Code. Used for: running the browser tests and drafting this comment. I reviewed the results.

Reply

Noruzzaman

Thank you so much for the detailed cross-browser testing and feedback, @courane01!

It’s fantastic to see the issues you flagged already getting quick attention and PRs from the Gutenberg team. Really appreciate your ongoing support for the 7.2 release!

Reply

opuswerk Polyglots ·

Hello Polyglots, I'm the author…

Hello Polyglots,

I’m the author of this 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. and would like to request PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. rights for German and German (Austria):

  • https://wordpress.org/plugins/opuswerk-delivery-delay-notices-for-woocommerce/

The German translations (du and Sie, code and readme) are already uploaded as suggestions, so the team can look at them first.

Thanks,
Yuri

opuswerk

Thanks for the de_DE rights, the German translations are approved now.
I’d also like to request PTE for German (Austria) and German (Switzerland):
o #de_AT – @ykamanin
o #de_CH – @ykamanin
The de_AT and de_CH translations (code and readme, both forms) are already uploaded as suggestions.

Reply

Sumit Singh Training ·

Meeting Agenda for October 20th, 2026

This week’s meeting will be held on Tuesday, October 13th, 2026, at 07:00 UTC. The meeting will be held 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/, in the #training channel. Anyone is welcome to contribute to the meeting by commenting in Slack threads during the meeting and throughout the following days. Meeting notes will be published by the following Tuesday to incorporate these asynchronous conversations as well.

This week’s meeting will be hosted by @sumitsingh.

1. Intro/Welcome

Welcome to all the new teammates who joined the Training Team this week!

2. News

  1. Meeting Note Takers
  2. Looking for feedback
  3. Looking for volunteers
    • Content Review Volunteers: Volunteers are needed to review and identify content that should be updated or consolidated. Two groups are needed: one for the handbook and one for courses.
    • Lesson Thumbnails: Work has started on creating thumbnails for lessons that need them. Team members are welcome to contribute to the remaining thumbnails through GitHub Issue #3428.
    • Issue Cleanup: The team discussed organising the many open issues into smaller categories and reviewing them systematically.
      • Review Workflow: The proposed process is to review issues one by one, identify outdated or irrelevant items, suggest next steps, and add comments before closing or updating issues.
        • Good First Issues: Contributors can start with issues labeled Good First Issue, especially those related to content feedback, and follow the handbook guide for validating feedback.
        • Issue Categories: The team discussed starting with a specific categoryCategory The ‘category’ taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging., with Bug issues suggested as a priority. Other options include Needs Translation Reviewer, Unlabeled, Awaiting Triage, and Content Feedback.
        • Next Steps: Team members are encouraged to suggest which category should be reviewed first, after which the issues can be divided among contributors.
      • Goal: Work together to clean up and keep the repository organised.
  4. Updates from last week’s Triage Squad session
    • No triage squad meetings last week
  5. Other announcements and news

2. Come and Contribute

3. Contribution Acknowledgement

  • Badges awarded:
    • No badges awarded this week

4. Project updates

  • A new version of the 50-hour course, WordPress Credits: Intro to Contribution, has been launched. It is integrated with the new Education Platform, where mentors can track student progress through student report cards.

5. Upcoming Online Workshops

  • No workshop scheduled

6. Contributor Updates

  • What have you been working on, and how has it been going?
  • Anything you’ve accomplished since the last meeting?
  • Do you have any blockers?
  • Can other contributors or Training Team members help you in some way?

7. Open Discussions

If you have topics you’d like discussed in the meeting, please leave them as a comment on this post.


You can see all meetings scheduled on this meeting calendar. If you are new to the Training Team, then come walk through our onboarding program to get to know the team and how we work. And if you have questions, feel free to reach out in the #training Slack channel at any time.

Rob Pugh Meta ·

The WordPress books now update from GitHub

The two books on wordpress.org/book, Milestones: The Story of WordPress and Building Blocks: The Evolution of WordPress, now come straight from WordPress/library on 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/. Merge a change there and it will go live on 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//book within the hour.

Until now, people edited the site and the GitHub repos separately, so fixes merged on GitHub were very delayed in reaching the site. In June, I spotted a typo in the GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples. chapter, and the fix sat in the repo for months. Footnotes also showed up as raw [footnote] brackets on every chapter.

What changed

  • Building Blocks now lives in WordPress/library next to Milestones, and I archived wp20-book, the repo where the community reviewed the book before its 2023 release. I went through its 13 open issues and pull requests, and the 9 fixes that still applied are now live.
  • Every hour, wordpress.org/book pulls in any chapters that changed, using the same importer as the handbooks.
  • The EPUB and PDF downloads rebuild on every change, so they always match the site.
  • Footnotes display properly now, and every pull request gets checked for broken ones.

How to make an update

Open an issue or a pull request on WordPress/library. Don’t edit chapters on the site itself, since the next import replaces them. The README covers the details.

Adding a brand-new chapter still needs one manual step, since someone with access to the book site has to create its page before the import can fill it.

If you have questions or something isn’t working, leave a comment below or ask in #meta on 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/.

Thanks to @obenland for reviewing the importer and switching it on. And thanks to @eidolonnight for the nudge.

Matt Mullenweg

Thank you! We can iterate and make these books so much better, and also maybe time to think about one covering our latest chapters. 🙂 Or should it all be one book and we just add chapters?

Reply

Benjamin Zekavica Core ·

Recap: WordPress 7.1 “Mary Lou” Retrospective

This post summarizes the feedback received from the WordPress 7.1 retrospective. Thank you to those who contributed their feedback via the retrospective survey and comments on the post!

For ease of reading, feedback has been synthesized. Full feedback is available for review in the anonymized form responses and comments to the original post.

Please remember that the following feedback are suggestions to bear in mind for future releases rather than action items for implementation. 

What would you keep?

  • The usual release parties and weekly check-in rituals.
  • Good communication throughout the release cycle, including security updates.
  • Security auditing, including handling all known high-risk HackerOne issues before deployDeploy Launching code from a local development environment to the production web server, so that it’s available to visitors..
  • Task lists for every role.

What would you add?

  • A kick-off call for the release squad, which helped the group work together and could be continued when time zones allow.
  • More emphasis on user documentation and on completing it on time.
  • Earlier visibility into user-facing 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 UIUI User interface changes. Some changes, such as the Elements panel and the GIF video block variation, were mainly documented in dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. or 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/ PRs, which made it harder for documentation contributors and for people supporting site editors to prepare.
  • Developers marking their tickets for dev notes or the field guideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. where appropriate, and writing their own dev notes.
  • Wider testing, for example by inviting hosts to test in their own environments and providing them with AI prompts to use on their setups.

What would you change, reduce, or remove?

  • Launching live at an event. One respondent felt it was not worth the added stress, and other members of the release squad agreed. If a release is tied to an event again, it helps when everyone involved follows the agreed schedule and arrangements during the event.
  • Better time zone overlap among release squad members where possible.
  • A request to bring back the official Docs role. Documentation work during a release is substantial, and only a few contributors currently have the experience to cover it.
  • More Learn content related to the release.

What else would you like to express about any part of the release cycle or release squad?

  • More contributors who can follow many parts of the project at once would help. This gap was noticeable in several places during the cycle.
  • More awareness of concerns 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. and theme ecosystem.
  • More automation, given how often the release process has been carried out.
  • The release squad communicated thoughtfully and was open to feedback, and respondents thanked the squad for their work.

Did you have an official role on the release squad during the 7.1 release?

This section describes if the survey participants are part of release squad or observer.

Did you contribute to the 7.1 release?

This section describes if the participants actually contributed to 7.1 release or not.

How did collaborating on this project feel?

This section included ways for one to indicate how much they agreed or disagreed with a statement around collaboration.

Would you like to be part of future release squads?

  • 25%: I have been part of a release squad and I will gladly repeat.
  • 50%: I haven’t been part of a squad but I would like to try in the future.
  • 25%: I have been part of a release squad but will not repeat in the near future.
  • 0%: I haven’t been part of a release squad and currently have no interest in it.

What is your feedback on the current release squad size?

Takeaways and next steps

  • Consider the impact before tying a release to a live event, and agree early on a schedule that everyone involved can follow.
  • Continue holding a kick-off call for the release squad, and consider time zone overlap when assembling the squad.
  • Find ways to share user-facing editor UI changes earlier with documentation and support contributors.
  • Encourage developers to mark tickets for dev notes or the field guide and to write their own dev notes.
  • Investigate which parts of the release process could be automated.
  • Find new ways to encourage wider testing during the 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 One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). period, for example together with hosts.
  • Make it clearer which contributors can follow many parts of the project and are available to help with specific areas.
  • Look at ways to connect more Learn content to each release.
  • Find ways to raise awareness of concerns from the plugin and theme ecosystem during the cycle.

Props to @annezazu for reviewing this post. 

#7-1, #retrospective

Emre Erkan Polyglots ·

How active are our Locale Managers and GTEs?

Hi everyone,

Every localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/’s team page lists its Locale Managers (LMs) and General Translation EditorsTranslation Editor Translation editors can approve translations for projects. The GTE (General Translation Editor) and LM (Locale Manager) roles can add new users with the “Project Translation Editor” role that can approve translations for specific projects. There are two different Translation Editor roles: General Translation Editor and Project Translation Editor (GTEs). I wanted to know how many of them are still active, so I collected the public data for all 203 localesLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ listed on translate.wordpress.org/stats and checked the profile of every LM and GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale. on profiles.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/.

I’m sharing the aggregate numbers here, not names. The goal is not to point at anyone. It’s to start a conversation about something many of us have noticed but rarely talk about.

The numbers

There are 870 unique people holding an LM or GTE role across 203 locales. Based on their most recent translation activity:

Last translation activity                 People   Share
Within the last 90 days                      273     31%
90 days to 1 year ago                        132     15%
More than 1 year ago                         315     36%
No recorded activity since mid-2022          150     17%

At the locale level (out of 203):

                                           Locales   Share
No LM or GTE active in the last 90 days         95     47%
No LM or GTE active in the last 12 months       74     36%
No LM active in the last 12 months              88     43%
No LM and no GTE at all                          4      2%

Locale Managers and GTEs look about the same: 33% of LMs and 28% of GTEs who aren’t also LMs were active in the last 90 days. So this isn’t about one group. Roles are granted, but nobody ever revisits them.

Why this matters

Becoming a GTE or PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. depends on an existing LM or GTE noticing and approving the request. When those people are no longer around, motivated contributors wait for weeks or months, get no answer, and often give up quietly. I know of more than one such case personally. I won’t share details, out of respect for the people involved.

The handbook has an Inactive Translations process, but it is triggered by the locale being two or more major versions behind. A locale can ship current language packs, thanks to a few active contributors, while most of its LMs and GTEs have been inactive for years. In that situation, nothing in the current process notices.

This is not a new topic

— Thinking about Inactive Translations (2014)
— Setting a clearer guideline for dealing with inactive translations (2019)
— Proposal: Polyglots Team Plans for 2021: see the discussion about inactive LMs in the comments
— A 2022 request from a contributor whose locale’s editors had been inactive for a long time

It comes up every few years and is never really resolved.

Some questions for all of us

1. Should holding an LM or GTE role come with an expectation of activity? What would be a fair definition, given that much of the work happens outside of GlotPressGlotPress GlotPress is the translation management software that powers Translate.WordPress.org. More information is available at glotpress.org.?
2. When a contributor’s LMs and GTEs don’t respond, what should they do, and how long should they have to wait? Do people even know the current process?
3. Would an “emeritus” or alumni status help people step back gracefully while keeping the recognition they earned?
4. Is there anything the data below misses?

I’d love to hear from LMs, GTEs, and especially from contributors who have been waiting for a role.

How I counted

Snapshot: October 19, 2026.
Sources: the locale list from translate.wordpress.orgtranslate.wordpress.org The platform for contributing to the translation of WordPress core, themes and plugins./stats, the LM and GTE lists from each locale’s team page, and each person’s contribution timeline on profiles.wordpress.org. Only public pages were used.
“Translation activity” means any of: translated stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings., reviewed strings, a comment on make.wordpress.org/polyglots, or a post on make.wordpress.org/polyglots.
Limitations:
— Translation entries on profile timelines only go back to mid-2022, so “no recorded activity since mid-2022” means exactly that.
— Activity isn’t tied to a locale, so the 34 people who hold roles in several locales may look more active per locale than they are.
— Work done 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/ or on local team sites isn’t counted.
— Someone who only translated a couple of strings counts as active, so the real picture is probably not better than this.

For transparency: I’m a Locale Manager myself (Turkish), so I’m part of these numbers too.

Peter Smits

I don’t think that this overview is complete, it is to general. It would be better to split it into the locales involved. As example we in nl_NL do have inactive GTE’ but also inactive PTE’s. The reason that PTE’s become inactive, is because they only handle the project they want to handle at that moment. Afterwards they do not get warnings when a project gets new strings or even waiting strings. So that needs improvement. Non active GTE’s is a different issue. They are supposed to follow up on waiting strings, but with the current overflow of AI and no means to handle them quickly, they are no longer motivated to handle them. PTE requests are generally handled properly, but that needs improvement as we already discussed with Toby.
I know Germany and France do handle PTE request, but probably other locales leave them hanging, as it would need work to check the request.
And honestly with the current overflow of AI translations and probably PTE requests, I think we do have a major problem. We would need to know exactly how many PTE requests are hanging, which I believe is not the issue, as Toby guards that.

Reply

Emre Erkan

Thank you, @psmits1567, for being the first to respond, and for sharing how things look in nl_NL.

You’re confirming what the numbers show: there are inactive GTEs in nl_NL too. That is exactly the pattern I wanted to make visible, and it’s not specific to one locale.

On the scope: I focused on LMs and GTEs on purpose, because they are the ones who open the door for others. The handbook describes GTEs as people who “typically act as community leaders in their locale”, and it says that “PTEs are appointed by a General Translation Editor” (Roles and Capabilities). So reviewing waiting strings is one part of the role. Appointing PTEs, mentoring and community building are part of it too. When a locale’s LMs and GTEs are inactive, nobody is there to grant access, however motivated the newcomers are.

On splitting the numbers per locale: I decided not to publish them. Many locales have only one or two LMs, so a per-locale figure would point at individual people, and that’s not the conversation I want to start. Every team can see its own LMs and GTEs on its team page. If it helps, I’m happy to share the nl_NL numbers with you directly.

The other points you raise are real issues, and I agree with them. My data doesn’t cover PTEs or PTE requests, so I can’t say anything about them. I think each of these deserves its own discussion, and I’d be glad to join if you or someone else starts one.

For this thread, I’d like to stay with the question of LM and GTE roles: what should we expect from the people who hold them, and what can contributors do when nobody responds?

Reply

Peter Smits

Emre, my opinion about your last remarks.
1. Nobody responds, that is exactly the point we have been discussing with Toby. For new translators information is hard to find ( my own experience) Only if GTE’s are actively monitoring the waiting strings, then you can prevent the ‘no responses’ If a complete GTE team is non active, then the overal manager should step in, and handle the requests. But that is something Toby tries to do. The overal structure is to weak currently, as it is solely up to the few people trying to keep up.
2. The rol of a GTE, that possebly needs to be redefined. Certainly if we get a database holding PTE requests.
3. We might need to assign not only GTE, but also define a teamleader rol. I have the impression that hearing long time discussions about glossary words, there does not seem to be such a rol.
Nobody takes a final decision about entries, causing endless discussions.

Reply

Emre Erkan

Thanks, @psmits1567. I think we agree on the core: the structure is too weak, and today it depends on a few people, @tobifjellner among them, trying to keep up.

Your idea of a database of requests made me curious, so I collected what is already public: every post tagged editor-requests since January 2022, and its comments. One post often asks for several locales, so I counted each locale separately and checked when an LM or GTE of that locale first commented.

Since January 2022
Request posts                                4,601
Locale requests (one post, several locales)  6,640
First answered by the locale's own LM/GTE      52%
Median time to that answer                     9 h
Never answered by the locale's own LM/GTE    2,622  (39%)
  of which handled only by Tobi              1,901

Two things stand out to me.

When a locale answers, it answers fast. The teams that are present are doing a good job.

In almost four out of ten requests, though, nobody from the locale ever answered. In almost three quarters of those, the only person handling the request was Tobi. Tobi also moderates these posts, so he is usually the first to see them. But that means much of the request handling depends on one person.

The volume is also growing quickly. From January to October 2026, there were already 2,821 locale requests: 2.4 times as many as in all of 2025, with two months still to go.

1. On responses: the fallback you describe already exists, but only when a locale has no active GTEs. The numbers show the other case: locales whose editors are partly active, or active but not responding to requests. There, nothing steps in except Tobi, and that won’t scale with this growth.

2. On a database of requests: the data above is a first approximation of it. A proper place for requests would make waiting requests visible and response times measurable for every team, without anyone having to collect them by hand.

3. On a team leader role: I wonder if we need a new role, or a clearer definition of an existing one. The handbook already gives Locale Managers extra responsibilities, such as appointing GTEs, but it doesn’t say who makes the final decision on things like glossary entries. Making that part of the LM role, or letting each team name a decision maker in its local handbook, might solve it without adding another layer.

A few notes on the data. LMs and GTEs are matched against today’s team pages, so people who answered back then but have since left count as “not the locale”. Requests handled on Slack, or granted without a comment, are not visible. Treat the numbers as an approximation, not an exact count.

It sounds like a few concrete ideas are taking shape here: a visible place for requests, expected response times, clearer LM and GTE responsibilities, and a path back for returning editors. I’d be happy to collect them into a follow-up proposal once more people have shared their views.

Reply

Emese

Thank you, Emre, for raising this important topic and sharing these findings.

As a General Translation Editor (GTE) for the Hungarian locale, I would like to share my personal experience and propose something that I believe deserves serious consideration.

I was inactive in the WordPress translation community for several years. Eventually, I returned because I genuinely love translating and missed being part of this wonderful community. Today, I am very active again, and I intend to continue contributing for many years to come.

My experience demonstrates that inactivity does not necessarily mean a permanent loss of interest or commitment. People sometimes step away for personal reasons, but they can return with renewed enthusiasm and dedication.

I fully agree that prolonged inactivity can create problems, especially when contributors are waiting for translation reviews, approvals, or responses from GTEs and Locale Managers. We need practical solutions to prevent these situations.

However, I strongly believe that we should not focus exclusively on inactivity. We also need to recognize, support, and motivate the people who are actively contributing.

Being a GTE is a responsibility. Reviewing translations carefully, maintaining consistency, helping contributors, and protecting translation quality all require time, patience, and dedication.

I believe the WordPress Polyglots community should consider introducing a meaningful recognition system for active and dedicated GTEs.

This could include special profile badges, periodic community recognition, or other forms of acknowledgment that highlight valuable contributions.

However, such recognition must never be based simply on the number of translations approved. That would risk encouraging quantity over quality, which is exactly what we should avoid.

Quality, reliability, constructive participation, and support for fellow contributors should matter far more than raw activity statistics.

I would also strongly support a clear and welcoming path for inactive GTEs who wish to return. Previous experience and knowledge should not automatically lose their value simply because someone has been away for a long time.

Of course, ensuring that contributors receive timely responses and that translation projects are not blocked must remain a priority.

But I believe our long-term goal should be broader: not only addressing inactivity, but building a community where contributors feel appreciated, supported, and genuinely motivated to stay.

Instead of asking only why GTEs become inactive, we should also ask what we can do to help them remain active — and what might encourage former contributors to return.

We are volunteers, but that does not mean our efforts should go unnoticed. Recognition cannot solve every problem, but it can make a meaningful difference.

Thank you for opening this important discussion!

Reply

Emre Erkan

Thank you, @naoko01, for sharing your story. Welcome back, and I’m glad you returned. ❤️

Your experience is a good example of why I asked about an “emeritus” or alumni status in the post. Stepping back shouldn’t mean losing recognition, and coming back should be easy. I agree that people who return deserve a clear and welcoming path, and that active editors deserve to be noticed.

There is another side to this that I’d like to add: the people who want to join.

Today, whether someone becomes a GTE or PTE depends entirely on the people who already hold the roles. Most locales have no published criteria for what makes a good candidate, no expected response time, and no clear way to appeal. The handbook’s fallback, where a Global Mentor can appoint a GTE, applies only “if there are no active GTEs for the locale” (Roles and Capabilities). So if a locale has editors who are active but don’t respond to a request, or turn it down without a clear reason, the contributor has nowhere to go.

I know motivated contributors who were turned away this way. Most of them don’t complain publicly. They simply stop contributing, and we never hear about them.

So, alongside recognition and a path back, I’d like us to think about the path in:

1. Should every locale publish its criteria for becoming a PTE or GTE, for example in its local handbook?
2. Should there be an expected response time for requests, and a clear next step when it passes?
3. Should a contributor be able to ask the Global Mentors for a second opinion, even when the locale has active editors?

Recognition helps people stay. Clear and fair access helps new people join. I think we need both.

Reply

Emese

Thank you, @emre, for your thoughtful response!

I would like to suggest a few practical ideas that could help both contributors and editors.

1. Voluntary availability status

GTEs and Locale Managers could indicate on their profiles whether they are currently available, temporarily unavailable, or taking a break. This would help contributors know whom they can contact without relying solely on activity statistics.

2. Automatic reminders and request reassignment

If a PTE request remains unanswered for a reasonable period, such as 14 days, the system could send a reminder and then forward it to another available GTE. This would prevent requests from being forgotten without automatically approving them or penalizing inactive editors.

3. Personal talk pages

What if WordPress.org profiles had a dedicated talk page, similar to Wikipedia? Contributors could leave questions, discuss translation decisions, and contact editors directly. Notifications and publicly accessible discussion histories could make communication more transparent and easier to follow.

4. Recognition of contributions beyond translation statistics

GTE activity involves much more than approving strings. Recently, I have been actively responding to PTE requests for the Hungarian locale, and I genuinely enjoy it. I always review applicants’ translations carefully before making a decision.

This work requires time, attention, and responsibility, even though it may not be fully reflected in activity statistics.

I believe active GTEs deserve meaningful recognition, such as permanent profile badges or public acknowledgments. However, recognition should be based on quality, reliability, and community support rather than the number of approved strings.

5. A welcoming path for returning contributors

As someone who returned after several years of inactivity, I believe it is important to make returning easy and welcoming. Previous contributions and experience should continue to be valued, even after a long break.

Ultimately, I believe we should not only address inactivity but also make contributing easier, improve communication, and give dedicated volunteers the recognition they deserve.

I would be interested to hear what others think about these suggestions!

Reply

Jamie Dąbrowiecki

I’ll have think about the wider question(s) and come back with a proper response later.

One thing I wanted to point out is that public WordPress.org user profiles don’t show the full story when it comes to translation activity.

If a GTE imports strings as “Current”, these are not logged on profiles. There could be some users that only translate via an external tool such as Poedit and then import.

I actually do this quite a lot, so my daily count looks far lower than it actually is.

It’s probably a low number of people, but worth taking into account.

Reply

Emre Erkan

Thanks, good catch. I knew about that bug, but it didn’t occur to me while I was working on the numbers. So the activity numbers in the post don’t account for imports, and they lean a little towards “inactive”. I’ll add it to the limitations.

Looking forward to your fuller response.

Reply

tobifjellner (Tor-Bjorn “Tobi” Fjellner)

I (aim to) keep track of PTE requests, to tick off handled requests, etc. I don’t look at a team’s page to judge their activity. Instead, I watch backlogs:
– https://translate.wordpress.org/stats/ and
– https://make.wordpress.org/polyglots/tag/editor-requests/?resolved=unresolved

Most locales depend on only 1-2 active GTEs, and when someone walks away, this often quickly changes the situation for their locale.
It would be good to have routines to reach out when there’s risk that a locale may fall behind.
With the enormous pressure we currently have from developers submitting thousands of strings to 10-20-30 they don’t speak, we right now have a huge risk that many locales will fall behind, due to people getting exhausted.

3. Would an “emeritus” or alumni status help people step back gracefully while keeping the recognition they earned?

There is no limited number of “LM/GTE seats” per locale.
But I actually have suggested before that we should have “honorary/emeritus” roles:
– If it’s obvious that someone isn’t active any more, this way newer contributors may feel more needed, and more willing to step up.
– Security-wise: if someone isn’t contributing, then it’s better to limit their capabilities/access, especially if they haven’t enabled two-factor authentication.
– When a locale tag is mentioned, all current GTEs receive notifications. An “emeritus GTE” should, obviously not be forced to see those notifications.
– There are many contributors, who maintained a locale for many years, and it would feel good to record some recognition on their profile.

Reply

Tommaso G. Scibilia

Sorry for the seemingly off-topic comment. Do we have a way to handle it when people pass away? What will happen when I die (hopefully of natural causes due to old age)? What will become of the team when the senior GTE or PTE dies?

Reply

tobifjellner (Tor-Bjorn “Tobi” Fjellner)

@masino1967
I requested “memorialisation” of profiles, but instead we got https://wordpress.org/remembers/ where we would be able to pay tribute to especially valuable contributors who have passed away.

Some of the global polyglots mentors and, ultimately, the meta team – can assign new LMs and/or GTEs if needed.

From each locale team’s perspective, it’s a good practice to try and not have too few key contributors. This adds resilience, and makes it easier if/when someone needs to step away some time.

Reply

Emese

I would also like to suggest another idea that could improve communication within the WordPress.org community.

What if every WordPress.org profile had a public talk page, similar to Wikipedia?

Contributors could leave messages, ask questions, discuss translation decisions, and refer back to previous conversations. Notifications for new messages would make communication even easier.

An optional online status indicator could also be useful. For privacy reasons, it could be visible only to logged-in users, with an option to disable it completely.

Of course, being online does not necessarily mean someone is available to review translations or respond to PTE requests. That is why I would also support a separate, voluntary availability status for GTEs and Locale Managers.

I believe these features could make communication more transparent, accessible, and welcoming, while respecting everyone’s privacy and personal time.

I would be interested to hear what others think about this idea!

Reply

tobifjellner (Tor-Bjorn “Tobi” Fjellner)

@naoko01
You mean, like Slack 🙂
Almost all locales have a /team site which can be used in this way.
If you want even more fine-grained communication, then we can add forums under a Rosetta site.
For instance, the Russian team uses a forum on their /support/ site for discussions around translations, https://ru.wordpress.org/support/forum/translations/

Reply

Emese

Thanks, Tobi! 🙂

Actually, I had something slightly different in mind.

I was thinking of personal talk pages directly attached to individual WordPress.org profiles, similar to Wikipedia user talk pages.

Contributors could visit someone’s profile and leave a public message without needing to join Slack, find the appropriate team site, or search through forum discussions.

Of course, only logged-in WordPress.org users should be able to post messages, while the discussions themselves would remain publicly visible and searchable.

Notifications would be essential. Users could receive WordPress.org notifications and optional email notifications whenever someone leaves a message on their talk page.

Slack, team sites, and forums are certainly useful, but not everyone uses Slack regularly. Personal talk pages would complement these existing tools rather than replace them.

I would also suggest an optional online status indicator, visible only to logged-in users, alongside a separate voluntary availability status for GTEs and Locale Managers.

Being online would not necessarily mean being available to review translations or respond to PTE requests.

I believe these features could make communication more accessible, transparent, and personal while respecting contributors’ privacy and time.

I hope this clarifies what I meant! 🙂

Reply

Yui

Do you mean something like WIki “User:” and “Usertalk” pages ?

https://codex.wordpress.org/Special:AllPages?from=&to=&namespace=3

—-
Thanks Emre for bringing up this topic and gathering stats. I’ve recently checked our SuperPTEs activity, its a stagnated too, there is nothing much to expect from our multi-category editors 🤷‍♀️

Reply

Emese

@fierevere Yes, exactly! 🙂 That’s what I had in mind!

I didn’t know that WordPress Codex already had MediaWiki-style user talk pages. Thank you for sharing this!

My idea would be to bring a similar feature directly to current WordPress.org profiles, rather than using a separate wiki.

Each user could have a public talk page where logged-in contributors could leave messages, with WordPress.org notifications and optional email notifications for new messages.

I think this could be especially helpful for communication between GTEs, PTEs, and other contributors.

It would be wonderful to have something like this integrated into our existing profiles! 🙂

Reply

Kamran Abdul Aziz

Thanks for putting numbers on this, Emre. An emeritus status could be the most respectful fix here, if it is built around choice and recognition. It fits well with Emese’s availability status: “away” for a break, emeritus for stepping back for good. A few ideas:

– Step back yourself: a “move to emeritus” option in your own settings, one click, no request needed.
– Keep what you earned: the badge stays on the profile with the years served, for example “GTE 2016–2026, Emeritus”, and the team page lists emeritus members separately. Like a grandfathered plan, the recognition never expires.
– Come back on request: a note to a Locale Manager restores the role without starting over, and Emese’s 14-day handover could cover the case where nobody answers.
– A gentle nudge for the rest: after 12 months with no translations, approvals or imports, a thank-you message offers emeritus. If there’s no reply in 30 days, the move happens automatically and can always be undone.
– Quiet but safe: no locale notifications and no approval rights while emeritus, but suggestions stay open.
– At least one active editor stays: no locale should end up with nobody able to approve.

Done this way, stepping back becomes a thank you rather than a removal, and newer contributors can see where they are needed.

Reply

tobifjellner (Tor-Bjorn “Tobi” Fjellner)

@ekamran
I like these ideas.
One exception: I wouldn’t suggest that the system should force “at least one active editor”. We’re all volunteers, and if the only editor of a locale wants to step away, they can still do it. But with an “emeritus” status, it will be visible to anyone, including the global mentors, that a locale currently has no active GTE.

Reply

Kamran Abdul Aziz

Fair point, agreed. Volunteers should always be free to step away, and visibility does the job better than a rule.

That suggests an easy first step: start with the voluntary part only. A self-service “step back” option with the emeritus badge, and nothing automatic. Nobody loses anything, anyone can come back, and mentors can see at a glance which locales have no active editor. If it works well, the gentle 12-month nudge can come later.

Reply

Francisco Torres Team Updates ·

Plugins Team: 19 Oct 2026

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. Status Change Stats

  • Plugins requested : 1363
  • Plugins rejected : 55
  • Plugins closed : 78
  • Plugins approved : 942

Plugin Queue Stats (current)

  • Plugins in the queue (new and pending)* : 5222
    • (older than 7 days ago)** : 4041
    • (2026-10-12 – 2026-10-18) : 832
    • (new; not processed or replied to yet)* : 457
    • (pending; replied to)* : 4765
    • (pending; waiting on author)* : 4023
    • (pending; waiting on reviewer)* : 510
    • (pending; waiting on reviewer, email not yet sent)* : 232

Help Scout Queue Stats

  • Total Conversations: 2454
  • New Conversations: 1482
  • Customers: 2080
  • Conversations per Day: 306
  • Busiest Day: Monday
  • Messages Received: 1689
  • Replies Sent: 4361
  • Emails Created: 1191

* : Stat reflects current size of queue and does not take into account ‘date’ or ‘day’ interval
** : Stat reflects activity only within the ‘recentdays’ from today

#plugins

Huzaifa Al Mesbah Test ·

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

dhruvkb Openverse ·

A week in Openverse: 2026-10-12 – 2026-10-19

openverse

Merged PRs

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.

  • #5627: Build admin read-only field links from DOM nodes
  • #5636: Update dependency requests to v2.33.0 [SECURITY]
  • #5642: Publish changelog for api-2026.10.13.16.37.55

Catalog

  • #5631: Pull the local S3 service from Chainguard’s MinIO image
  • #5634: Update dependency filelock to v3.20.3 [SECURITY]

Documentation

  • #5629: Create Storybook’s settings directory in the Playwright image
  • #5642: Publish changelog for api-2026.10.13.16.37.55

Frontend

  • #5539: Update dependency storybook to v8.6.17 [SECURITY]
  • #5629: Create Storybook’s settings directory in the Playwright image
  • #5630: Update vulnerable JS dependencies in the pnpm lockfile
  • #5632: Update dependency adm-zip to ^0.6.0 [SECURITY]
  • #5633: Update dependency axios to v1.20.0 [SECURITY]
  • #5637: Update dependency uuid to v11.1.1 [SECURITY]
  • #5639: Update dependency vitest to v4 [SECURITY]

Management

  • #5628: Update Renovate action to v46 so pnpm security updates apply
  • #5636: Update dependency requests to v2.33.0 [SECURITY]
  • #5641: Pass the 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/ token to the docs-check CI steps

Closed issues

#openverse, #week-in-openverse

Alkesh Miyani Training ·

Training Team Meeting Recap – 13th October 2026

This meeting followed the meeting agenda in GitHub and P2 Post. You can see conversations from the meeting in this Slack Log. (If you don’t have a 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/ account, you can set one up.)

Introductions and Welcome

There were 21 attendees: @jenish1234, @pravin1996, @rfluethi, @harshjadav003, @csheba, @vasantrajput, @freewebmentor, @gohelkunjan, @alkesh7, @makanikaran, @dilip2615, @rjekic, @sumitsingh, @andrewssanya, @sibokul, @nitspatel (async), @sonaliprajapati (async), @ursha (async), @mohkatz (async), @valeriewandeler (async), @ravigadhiyawp (async)

Newcomers: @preet713, @jair187, @pamelasibaja25, @abelvargas, @potencialconsulting
Meeting hosted by: @devmuhib
Note Taker: @alkesh7
Note Reviewer: @vasantrajput

Welcome! Please post in the #training channel or reach out to a team member to help you with contributing. Resources to check out our onboarding program and our Guide Program.

News

Meeting Note Takers

Here is our current note taker roster:

Important note: If anyone needs more information on note-taking or a guide to creating a Recap Note Post, they can DM Vasantsinh Rajput. He will guide you on a Recap Note, and he will review & publish your Recap Post.

Looking for feedback

  • WordPress Hackathon: Recently, we tried a WordPress Hackathon at Stamford University, Bangladesh, alongside the WordPress Campus Connect event. We have created a community blog post where you can share your feedback.
  • Team Homepage: @clk87 has shared A block-based prototype for the Training Team homepage to make team pages more engaging and newcomer-friendly. Feedback is welcome via GitHub Issue #3674.
  • Office Hours: The next Office Hours will be held on a weekday, avoiding Monday and Friday. The proposed dates are October 27, 28, or 29, 2026. You will be informed when the date is set and confirmed.
    • Current Voting:
      • 1 vote for 27th October
      • 2 Votes for 28th October
  • Text-to-Speech: The team discussed exploring text-to-speech/read-aloud functionality for course lessons. @softglaze has created prototypes, and the team is encouraged to provide feedback before implementation discussions with the 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. Team.
  • Training Team Handbook: The handbook is currently being updated, and team members are encouraged to share suggestions, improvements, and ideas in GitHub Issue #3447.
  • Intermediate 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. Developer Course: @mebo has revived the Learning Pathway course and started working on modules and lessons. Team members are invited to review the new content and share feedback, including the “Rendering plugin data” lesson.

Looking for volunteers

  • Content Review Volunteers: Volunteers are needed to review and identify content that should be updated or consolidated. Two groups are needed: one for the handbook and one for courses.
  • Lesson Thumbnails: Work has started on creating thumbnails for lessons that need them. Team members are welcome to contribute to the remaining thumbnails through GitHub Issue #3428.
  • Issue Cleanup: The team discussed organising the many open issues into smaller categories and reviewing them systematically.
    • Review Workflow: The proposed process is to review issues one by one, identify outdated or irrelevant items, suggest next steps, and add comments before closing or updating issues.
      • Good First Issues: Contributors can start with issues labeled Good First Issue, especially those related to content feedback, and follow the handbook guide for validating feedback.
      • Issue Categories: The team discussed starting with a specific categoryCategory The ‘category’ taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging., with Bug issues suggested as a priority. Other options include Needs Translation Reviewer, Unlabeled, Awaiting Triage, and Content Feedback.
      • Next Steps: Team members are encouraged to suggest which category should be reviewed first, after which the issues can be divided among contributors.
    • Goal: Work together to clean up and keep the repository organised.

Update for last week’s triage squad

N/A

Other news

Come and Contribute

This week’s contribution focus area

  1. Content ready for review
  2. Feedback awaiting validation
  3. Topics awaiting vetting
    • See Vetting Topic Ideas for step-by-step guidance on vetting topic ideas.
    • We have 2 issues that require vetting
  4. Validated feedback awaiting fix

Contribution Acknowledgement

Badges Awarded

  • Congratulations @softglaze for the Training Contributor Badge Awarded.

Give Props

  • N/A

Project updates

  • A new version of the 50-hour course, WordPress Credits: Intro to Contribution, has been launched. It is integrated with the new Education Platform, where mentors can track student progress through student report cards.

Upcoming Online Workshops

  • N/A

Contributor Updates

  • N/A

Open Discussions

  • Suggestion (by @devmuhib): Move Open Discussion and Contributor Updates Earlier in the Meeting
    • Could we consider moving the Open Discussion and Contributor Updates sections to the beginning of the meeting instead of keeping them at the end? This would give everyone an opportunity to participate and share their updates without having to wait until the end of the meeting.
      • @rjekic: I agree, but I am not sure it will change anything, since there are no many active members willing to say something
      • @rfluethi: I like this. We discussed it in detail at the last Office Hours meeting, and Vasant made a really good suggestion there. Why don’t we implement it that way?
      • @devmuhib: Rico, I had a WPCC event, so I missed that. But if you all are agree on a topic, I think we can definitely try to implement that.
      • @vasantrajput: Yes, I agree with that, And we already discussed that into last office Hours Metting. And many more points discussed to improve the weekly meeting and make more engaging and involve contributors. And all details @Rico has mentioned in the recap post. So we can start implementing that.
      • @devmuhib: Great! Thanks team, we can create a draft and make changes.
      • @rjekic: I agree also, we can implement it on next meeting
      • @sumitsingh: Nice suggestions
      • @andrewssanya: Think its a fresh intro that I will capture everyone
  • Suggestion (by @rjekic): Can we change the scheduled time of the Training Team meeting?
    1. Here in Serbia, we switch to standard time on the last Sunday in October, so it will be difficult for us to attend the Training Team meeting, since it starts at 8 AM local time. It’s going to be tough for all of us in Europe, USA and Canada who observe daylight saving time, since the clocks will be going back an hour.
      • @vasantrajput: @rjekic, also please suggest 2-3 options for timing so others can also check the local times.
        And also, we can try for 2-3 meetings and check the times change is it works for everyone or not.
      • @rjekic: I would propose a small change to 08:00 UTC (one hour in advance).
    2. @clk87: Can we please work towards a date/time to launch the new homepage?
      • @devmuhib: @clk87 do you have any date suggestions? I think we will help us to discuss if people related to this release are available or not.
      • @clk87: How about this time next week or early the following? We could look at Tuesday 27th. I currently have a clear afternoon that I can dedicate to implementing the new homepage design.
        I don’t think we’ll need to ask a meta developer to implement the page or anything. As far as I’m aware, I should be able to implement the new design on the Welcome page.
        Please let me know your thoughts.
      • @devmuhib: I am available at 27th.
      • @sumitsingh: I am available on the 27th too but what time do I need to do?
      • @rjekic: I am available also.
      • @devmuhib: I think that day we have meeting. So can we join 1 hour after the weekly meeting? I mean 9 UTC?
      • @sumitsingh: Better to do it after 2 hours if possible please

Thanks to everyone who participated in the sync and async, and to those who will contribute in future sessions.


You can see all meetings scheduled on this meeting calendar. If you are new to the Training Team, then come walk through our onboarding program to get to know the team and how we work. And if you have questions, feel free to reach out in the #training Slack channel at any time.

#meeting-recap, #training, #training-team

Teams

  • Core

    The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team makes WordPress. Whether you’re a seasoned 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, 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., 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 or CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. developer or are just learning to code, we’d love to have you on board. You can write code, fix bugs, debate decisions, and help with development.

  • Design

    The design group is focused on the designing and developing the user interface. It’s a home for designers and UXers alike. There are regular discussions about mockups, design, and user testing.

  • Mobile

    The mobile team builds the iOSiOS The operating system used on iPhones and iPads. and Android apps. Lend them your Kotlin, Swift, or ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org Native skills. The team also needs designers, UXUX UX is an acronym for User Experience – the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. experts, and testers to give users a smooth experience on every device.

  • Accessibility

    The a11yAccessibility 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) group provides 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) expertise across the project. They make sure that WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and all of WordPress’ resources are accessible.

  • Polyglots

    WordPress is used all over the world in many different languages. If you’re a polyglot, you can help by translating WordPress into your own language or contributing to the GlotPress project, making translations easier and more effective for everyone.

  • Support

    Answering questions in the support forums, IRC, or 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/ is one of the easiest ways to start contributing. Everyone knows the answer to something! Since the forums run on bbPress, you can also contribute by helping make the software behind them even better.

  • Documentation

    Good documentation lets people help themselves when they get stuck. The docs team is responsible for creating documentation and is always on the look-out for writers. The blog has discussion around the team’s current projects.

  • Themes

    The Theme Review Team reviews and approves every Theme submitted to the WordPress Theme repository. Reviewing Themes sharpens your own Theme development skills. You can help out and join the discussion on the blog.

  • Plugins

    If you are a 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. developer, subscribe to the Plugin review team blog to keep up with the latest updates, find resources, and learn about any issues around Plugin development.

  • Community

    If you’re interested in organizing a meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. or 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., the community blog is a great place to get started. There are groups working to support events, to create outreach and training programs, and generally support the community.

  • Meta

    The 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. team makes 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/, provides support, and builds tools for use by all the contributor groups. If you want to help make WordPress.org better, sign up for updates from the Meta blog.

  • Training

    The WordPress training team helps people learn to use, extend, and contribute to WordPress through synchronous and asynchronous learning as well as downloadable lesson plans for instructors to use in live environments, via learn.wordpress.org.

    If you enjoy teaching people how to use and build stuff for WordPress, immediately stop what you’re doing and join our team!

  • Test

    The Test Team works to improve WordPress quality and usability by advancing the development process through manual and automated testing. Whether through a browser, app, terminal, or code, the team focuses on testing across the entire WordPress ecosystem, including CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and 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/, mobile apps and themes, and feature plugins and importers.

  • TV

    The TV team reviews and approves every video submitted to WordPress.tv. They also help WordCamps with video post-production and are responsible for the captioning and subtitling of published videos. Reviewing videos is a great way to learn about WordPress and help the community: experience is not required to get involved.

  • Marketing

    The Marketing team is currently archived to make room for an experimental shift in focus and processes. Check out the WordPress Media Corps to learn more. Amplification requests and Showcase activities are still running, and you can find out more about them on GitHub.

  • CLI

    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/ is the official command line tool for interacting with and managing your WordPress sites.

  • Hosting

    The Hosting team maintains distributed testing software that tests pre-release versions of WordPress on hosting systems, and infrastructure-focused documentation.

  • Tide

    Tide is a series of automated tests run against every 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. and theme in the directory and then displays 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 compatibility and test errors/warnings in the directory.

  • Openverse

    Openverse is a search engine for openly-licensed media. The Openverse team implements new features and new media types; maintains the public 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. and front-end search engine; and develops WordPress integrations to share Openverse with the entire WordPress community.

  • Photos

    The Photo Directory team moderates every photo submitted to the WordPress Photo Directory, maintains and improves the directory site itself, and provides resources and documentation to educate, encourage, and facilitate photo contributors.

  • Core Performance

    The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. performance team is dedicated to monitoring, enhancing, and promoting performance in WordPress core and its surrounding ecosystem.

  • Playground

    The Playground team works on WordPress Playground: the platform that lets you run WordPress instantly on any device without a host, most often in a browser.

  • Core AI

    The CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. AI Team coordinates and accelerates AI efforts across the project, focusing on responsible innovation that aligns with WordPress values. We use a 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.-first approach to explore AI-powered features, share a public roadmap, and collaborate with other teams.

  • Core Program

    The CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Program team is focused on strengthening coordination across teams, improving efficiency and empowering contribution. It’s a home for those who span across product and project work.

All teams and their meetings

Not sure which team to contribute to?

Check out our contributor wizard and find how to get started.