Image Pooja Derashri 12:04 pm on March 12, 2024  

Highlighted Posts

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

Image Nikunj Hatkar 3:52 pm on March 10, 2026
Tags: ,   

X-post: Test Team Update: 10 March, 2026

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

Image Jonathan Desrosiers 1:35 am on March 10, 2026
Tags: ,   

X-post: Call For Feedback: Increasing Value of Release Party Testing Phase

X-comment from +make.wordpress.org/core: Comment on Call For Feedback: Increasing Value of Release Party Testing Phase

Image Moses Cursor Ssebunya 5:07 am on March 4, 2026  

Month in Test: March 3, 2026

Hello and welcome to another edition of Month in Test, the place where contributors of any skill level can find opportunities to contribute to WordPress through testing. You can find the Test Team in #core-test.

Table of Contents

Calls for Testing 📣

Calls for Testing can originate from any team, from themes to mobile apps to feature plugins. The following posts highlight features and releases that need special attention:

Test Handbook 📘

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

For the last few weeks, a good number of test contributors embarked on the journey of reviewing our new Test Handbook based on GitHub. The Process has been concluded successfully with the merging.

  • We want to inform that the Test Handbook is officially synced. There might be a couple of bugs and things that are not looking good pending to be fixed.
  • Feel free to give it a check here, and if you find any bugs, go to the GitHub repository and report them.
    • You can send a PR with the fix, or simply send the issue, and we will check it

Weekly Testing Roundup 🤠

Bi-Weekly update: Test Team Update

Here’s a roundup of active tickets that are ready for testing contributions. Did you know that contributions to the Test Team are also a fantastic way to level up your WordPress knowledge and skills? Dive in to contribute, and gain coveted props 😎 for a coming release.

1. WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Testing

a. Patch Testing 🩹

Who? All contributors (not just developers) who can set up a local testing environment. Why?
It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.

The following tickets (4) have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:

b. Bug Reproduction

It is necessary to confirm if the bug is happening under multiple conditions and environments, using the bug reproduction report in order to validate the issue.

The following tickets (141) have been reviewed and milestoned, and need testers to check the instructions and manually test if the issue is reproducible, then provide a bug reproduction report:

c. Test Team Issues

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

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

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

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

a. Gutenberg Bug Reproduction Testing

The following tickets (3) have been filed reporting a known bug and needs testers to manually test, then provide feedback through a bug reproduction report that the issue can be reproduced.

b. Gutenberg Patch Testing

All contributors (not just developers) who can set up a local testing environment.
Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.

The following tickets (1) have been reviewed, and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:

Profile Badge Awards 🎉

Congratulations to the recipients of the Test Contributor Badge 🎉

  • none this Month

– Kindly find the Contribution Guidelines here

Read/Watch/Listen 🔗

  1. WordPress Ecosystem Announcements
  2. Test Team Announcements
    • Weekly Patch Testing Scrub: Tuesday at 15:00 UTC (runs every week)
    • Weekly Test Chat: Thursday at 15:00 UTC (runs every week)
    • Monthly Voice Test Chat: First Thursday of each month at 15:00 UTC
  3. Call for Testing

Upcoming Meetings 🗓

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

Current 2026 Schedule:

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

Props to @nikunj8866 for helping review this article and offering feedback

Image ramonopoly 1:03 am on February 27, 2026
Tags: patterns,   

Call for Testing – Pattern editing and content-only interactivity in WordPress 7.0

This is a follow up post to Help Test WordPress 7.0 with specific details about a new way to edit patterns in the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor.

Pattern Editing and content-only Interactivity is a significant change to how patterns behave in the WordPress editor, arriving in WordPress 7.0. 

Unsynced patterns and template parts inserted into the editor now default to content-only mode, prioritizing the editing of text and media without exposing the deeper block structure or style controls.

If you have a few minutes or more, we’d love to hear your feedback on the feature in the coming week to allow time for fixes before the release candidate phases.

Table of contents:

What is content-only mode?

Content-only mode is the default experience when clicking into an unsynced pattern or template part in WordPress 7.0. Here’s what it means in practice:

What you can edit:

  • Text in Paragraph, Heading, and other text blocks
  • Images (swapping the image source, updating alt text and caption)
  • Links and button labels
  • Any block attribute that a block author has explicitly marked with "role": "content" in their block definition
  • New Paragraph, List item, Button and other “list” type blocks can be inserted directly into content areas without unlocking the full pattern

What is protected:

  • Block structure (you can’t add, remove, or reorder structural blocks like Groups and Columns)
  • Spacing, colors, typography, and other style settings
  • Any block attribute not marked as content

In the editor, protected blocks are visible but non-selectable — you can see the layout, but clicking on a structural wrapper won’t open its controls.

Why content-only by default?

In WordPress versions previous to 7.0, clicking into a pattern immediately exposed every inner block for editing, including structural and container blocks, all block styles and block attributes. 

This default editing mode is convenient for theme builders and developers who create patterns. For users who only want to update a heading or swap an image however, it presents an overwhelming and error-prone experience. Small misclicks can accidentally restructure a layout or remove a block entirely.The goal of content-only mode is to separate what content a user edits from how a pattern is structured. With this change, patterns behave more like intentional design components: users can update the content they’re supposed to update, and the underlying structure stays protected unless explicitly opened for editing.

More features

Adding new content inside a pattern

You can insert new Paragraph blocks (and other content-type blocks like list items and buttons) directly into designated content areas of a pattern without entering the full structural editor.

This means a pattern with a text area behaves more like a writing surface — you can append or insert new paragraphs within the allowed zone without needing to “unlock” the pattern first.

List View

Image

Non-active blocks are hidden in List View when editing a pattern gives you context while keeping the focus clear.

Support for complex blocks

Buttons, List, Gallery, and Social Icons blocks have a list view in the block inspector 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. in content-only mode, so child blocks can be selected and edited without exposing full block controls.

Image

An opt-out for developers

A new disableContentOnlyForUnsyncedPatterns editor setting lets theme and 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. developers disable content-only mode for unsynced patterns when needed. For example, during theme development when you want unrestricted access. This can be set via the block_editor_settings_all 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/preface.php 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.:

add_filter( 'block_editor_settings_all', function( $settings ) {
    $settings['disableContentOnlyForUnsyncedPatterns'] = true;
    return $settings;
} );

Or via 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/.:

wp.data.dispatch( 'core/block-editor' ).updateSettings( {
    disableContentOnlyForUnsyncedPatterns: true,
} );

Editing pattern design

Making design and structural changes to a pattern works differently depending on the type of pattern you’re editing.

Unsynced patterns

Clicking the ‘Edit pattern’ button or double-clicking the body of a pattern temporarily “unlocks” the pattern, exposing its inner blocks and full editing capabilities.

Synced (synced patterns / template parts)

Clicking the ‘Edit original’ button takes you to an isolated editor when you can make any changes to the underlying pattern. The editor 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. provides navigation back to the originating document. Changes to synced patterns apply globally.

How to Test

Testing Environment

The Help Test WordPress 7.0 post sums up how to test WordPress Beta, including instructions on how to test on local site on your computer.

The quickest way to test is with WordPress Playground.

What to Test

You don’t need to test everything — pick what matches your use case.

Scenario 1: Editing content inside a pattern as a user

Try this if you: Want to experience the feature from an end-user perspective.

Steps:

  1. In the site editor or post editor, insert an unsynced pattern that contains paragraph text and an image (most patterns from the pattern inserter will work or you can create your own).
  2. Open the List View CTRL + OPTION + O. Only the pattern’s content blocks should be visible.
  3. Edit the paragraph and/or replace the image. In the paragraph block, hitting “Enter” should create a new paragraph.
  4. Now select the pattern and click the “Edit pattern” button in the toolbar or block inspector sidebar.
  5. You should be able to modify the content block’s styles, or delete the block entirely.
  6. Try clicking on (or inserting) a block you wouldn’t normally want a user to edit (e.g., a Group block used for layout).

What we’d love feedback on:

  • Is it clear which content you can and can’t edit?
  • Is the overall experience less confusing than before?
  • Did you accidentally break anything?

Scenario 2: Opening a synced pattern or template part for structural editing

Try this if you: Want to test the isolated editor and navigation flowFlow Flow is the path of screens and interactions taken to accomplish a task. It’s an experience vector. Flow is also a feeling. It’s being unselfconscious and in the zone. Flow is what happens when difficulties are removed and you are freed to pursue an activity without forming intentions. You just do it..

Steps:

  1. Open up a template that has a template part (e.g., Blog homepage that contains the Footer template part). 
  2. Open the List View CTRL + OPTION + O. Only the template part’s content blocks should be visible. 
  3. Click “Edit original” on the pattern or template part.
  4. Verify the isolated editor opens with a breadcrumb showing your location.
  5. Make a structural change (add or remove a block).
  6. Use the “Back” button and confirm you return to the originating document.

What we’d love feedback on:

  • Is the navigation between the document and the pattern editor clear?
  • Does “Back” return you to the right place?
  • Are breadcrumbs helpful?

Scenario 3: Testing with custom blocks or patterns

Try this if you: Build themes, plugins, or custom blocks.

Steps:

  1. Register a custom block with attributes that should be user-editable. Test whether adding "role": "content" to those attributes makes them accessible in content-only mode.
  2. Register a custom unsynced pattern and insert it in the editor. Confirm it enters content-only mode by default.
  3. Try the disableContentOnlyForUnsyncedPatterns opt-out via the PHP filter and confirm unrestricted editing is restored for unsynced patterns.
  4. Check that template parts and synced pattern views remain unchanged  regardless of the opt-out setting.
Test block with role (you can paste this block into the browser console when in the editor) 
wp.blocks.registerBlockType( 'test/visibility-with-role', {
	apiVersion: 3,
	title: 'Test Block (with role)',
	category: 'text',
	attributes: {
		message: { type: 'string', default: 'Edit me (with role)', role: 'content' },
	},
	edit: ( { attributes, setAttributes } ) => {
		return wp.element.createElement(
			wp.blockEditor.RichText,
			{
				tagName: 'p',
				value: attributes.message,
				onChange: ( val ) => setAttributes( { message: val } ),
			}
		);
	},
	save: ( { attributes } ) => {
		return wp.element.createElement(
			wp.blockEditor.RichText.Content,
			{ tagName: 'p', value: attributes.message }
		);
	},
} );

What we’d love feedback on:

  • Does “role”: “content” behave as expected for your block’s attributes?
  • Are there blocks that should be editable in content-only mode but aren’t?
  • Does the opt-out work reliably?

Scenario 4: Edge cases and multi-block patterns

Try this if you: Want to help find bugs.

Ideas to test:

  • Insert a pattern containing Buttons, List, Gallery or Social Icons and verify individual items can be selected and edited in content-only mode.
  • Test with nested patterns (a pattern inside a pattern).
  • Try undoing and redoing edits made inside content-only mode.
  • Test with multi-selecting blocks that span inside and outside a pattern.

What we’d love feedback on:

  • Does anything break or behave unexpectedly?
  • Are there patterns in the pattern library that are unusable in content-only mode?

How to Share Feedback

Comment on this post with your findings, or file 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/ issues in the WordPress/gutenberg repository and link to them here.

Helpful to include:

  • Browser, OS, and WordPress version
  • Screenshots or recordings
  • Steps to reproduce any issue
  • Severity assessment

Example:

Clicking a Button block inside a pattern opens full block controls instead of content-only mode

Steps to reproduce:

1. Insert the "Call to Action" pattern
2. Click the Button block inside it

Expected: Only button text is editable
Actual: Full toolbar and sidebar controls appear

Severity: Medium

WordPress: 7 Beta
Browser: Chrome 145.0.7632.110, MacOS
Theme: Twenty Twenty-Five

Resources

Thank you for making it this far and for testing!

Your feedback will directly shape how this feature lands in WordPress 7.0 and what gets improved in future releases.

Props to @ankit-k-gupta, @andrewserong and @talldanwp for helping to write this post.

#patterns, #wordpress-7-0

Image Nikunj Hatkar 9:38 am on February 24, 2026
Tags: ,   

X-post: Test Team Update: 24 February, 2026

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

Image Ankit K Gupta 12:57 pm on February 20, 2026
Tags: , ,   

Help Test WordPress 7.0

WordPress 7.0 — the first 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 April 9, 2026.

With the launch of 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, it’s time to start testing everything. That’s the best way to make sure this WordPress is stable, reliable, and easy to use for users across the globe.

Early testing is critical.

It finds bugs, usability issues, and compatibility concerns while there’s still time to address them. 

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

Got a few minutes? A few hours? Every bit of testing makes a big difference — possibly, the difference between a new feature landing in 7.0 or not.

Stay informed!

The WordPress 7.0 release 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.0 into the strongest, most polished release ever. 

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

🧪 Testing Tips

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

Simply use WordPress as you would every day (on a test installation, of course!)

Run WordPress hard. Take it through processes that mimic your projects, workflows, and experiments. Try to break things.

Notice something unexpected? Run into a bug? Is a feature not behaving the way you thought it would? Please consider reporting it.

Not sure what the expected behaviour should be? No problem! Join the conversation in the `#core-test` channel on the Making WordPress Slack, where contributors and developers are always happy to help. If you’re comfortable with the ticket system, you can also create a ticket on WordPress TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.. 

New tester? You have the global WordPress community at your service. Everyone in it is happy to welcome and support you. 🌍

Again, every report, question, or observation you submit makes a difference and helps improve WordPress for hundreds of millions of users.

Recommendations for Testing WordPress Beta/RCRelease 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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Features that Matter to You:  Use your site the way you usually do. For instance, if you’re a blogger, running a social platform, or managing an e-commerce store, run your tests through those specific scenarios.
  • Set up a staging site (ask your hosting provider if this is new to you). Do not test or update your live site with a beta version for testing; your users might see any issues that come up.
  • Update WordPress in the staging environmentStaging 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. 
  • Use the General Checklist below to verify everything works as you’d expect.

How to test WordPress Beta Versions 

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

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

WP-Playground

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

A Local Site on your computer 

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

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., which lets you install pre-release versions of WordPress.
  4. Switch to the development or beta version of WordPress:
    1. Navigate to Tools > Beta Testing.
    2. Choose between Bleeding Edge or Point ReleaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. Nightlies, depending on what you want to test.
    3. Click Save Changes, and 
    4. Update your WordPress version.

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:

  • Create a local WordPress site, however you like to do it. Wait for the notification that your site is ready.
  • Open your terminal and navigate to the root directory of your WordPress installation.

Run the following command to update to the latest beta version:

wp core update --version=7.0-beta1

Or

wp core update --version=7.0-RC1

(Replace the version number as needed, such as – -version=7.0-beta2.)

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

A Staging Site on your host

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

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

Testing Patches

Maybe you don’t need to test an entire version of WordPress, but you do need to test one or more patches.

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

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

If you want to quickly test the updated WordPress version’s compatibility with your site, please verify the following checks:

First, update your WordPress to the Beta/RC version, enable debugging in wp-config.php, and update your theme and plugins.

  • Ensure plugins and themes didn’t deactivate automatically after the update.
  • Check the WordPress Site Health tool for any new warnings or issues.
  • Confirm there are no layout breaks or misaligned elements.
  • Test links and permalinks to ensure there are no 404 errors.
  • Verify that posts, images, and media are displayed correctly.
  • Ensure the sitemap and robots.txt files are functioning properly.
  • Ensure full access to the admin dashboard without errors.
  • If your site has custom blocks, create content in a new 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. and edit existing content.
  • Create a new post: add content, copy-paste text, and manually add media files. Save the post and observe the console for any issues.
  • Create a new page, add content, and check its display in different browsers.
  • Open the browser’s developer console and check for any errors, warnings, or notices.
  • Open the error log file and check for notices, warnings, and fatal errors.
  • Review user roles and permissions to ensure they remain intact.
  • Verify that any scheduled posts or automated tasks (like backups) still function as intended.
  • Ensure all integrated services (like payment gateways or analytics) are operational.
  • Open your site in different browsers and verify that all functionalities work as expected.
  • Check site performance and loading speed after the update.
  • Verify 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 such as keyboard navigation, contrast, and screen reader behavior where possible.
  • Test form submissions (contact forms, checkout forms, login forms, etc.).
  • Confirm media uploads, image editing, and gallery functionality work properly.
  • Test theme customization settings (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. or Site Editor) for stability.

WordPress continues to work reliably for the diverse global community that depends on it.

If anything fails here, it can directly impact revenue, so prioritise fixing these issues before updating production.

👉 Key Features to Test

Visual RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.

Visual revisions in WordPress 7.0 let you see and restore past versions of a post directly inside the editor, with clear visual highlights of what changed. You get a new “Revisions” view instead of being taken to a separate screen, with a timeline/slider to move between older and newer revisions. The content canvas shows visual diffs where added text is highlighted in green, removed text in red, and formatting changes like links or bold in yellow, while changed, added, and deleted blocks are visually marked so you can quickly see which parts of the page changed. In this mode, you can inspect and restore a revision, but you cannot edit content directly, keeping the experience focused on review and recovery.

Testing Steps

  1. Create content and revisions
    • Create a new post or page.
    • Add a few different blocks (Paragraph, Heading, List, Image).
    • Make several changes and click Update each time (add text, remove text, change formatting, add/remove blocks).
  2. Open the in‑editor revisions view
    • In the editor, open the post 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. (Document/Settings).
    • Click the Revisions link/count.
    • Confirm you stay in the editor and see a dedicated revisions 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. and slider.
  3. Use the slider/timeline
    • Move the slider to older and newer revisions.
    • Confirm the canvas updates to show the selected revision and that the current revision is clearly indicated.
  4. Check visual diffs
    • Verify:
      • Added text is highlighted in green with an underline.
      • Removed text is highlighted in red with strikethrough.
      • Pure formatting changes (e.g., turning a word into a link, making it bold) are shown in yellow (outline/underline).
    • Confirm that changed/added/deleted blocks are visually distinguished from unchanged blocks.
  5. Scroll markers/navigation
    • Look for markers along the scroll area that show where changes exist.
    • Click a marker and confirm the view jumps roughly to the changed area.
  6. Selection and non‑editing
    • Click on blocks in the revision view.
    • Confirm you can select and inspect them, but cannot type, add new blocks, or move blocks around.

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

Font Library Support for More Theme Types

WordPress previously introduced the Font Library to allow users to upload, manage, and apply fonts directly within WordPress without relying on themes or additional plugins. With updates targeted for WordPress 7.0, this functionality is expanding beyond block themes to better support classic themes as well.

This enhancement means site owners using classic themes can now access font management features in a more consistent way, similar to how media assets are handled. A dedicated Fonts page now appears under Appearance → Fonts for classic themes (not just block themes), where users can upload, activate, and manage fonts centrally.

Once added, these fonts become available within block editor typography controls — for example, selecting a font family from the Paragraph block settings — helping provide a more unified typography experience across different theme types.

Testing Steps 

Verify Font Library Availability in Classic Theme

  1. Install and activate a classic theme (e.g., Twenty Twenty-One or similar).
  2. Navigate to Appearance → Fonts.

Expected:

  • The fonts page should appear even with a classic theme.
  • No 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. breakage or missing styles.

Upload Custom Fonts

  1. Go to Appearance → Fonts.
  2. Upload a supported font file.
  3. Activate the uploaded font.

Expected:

  • Font uploads successfully.
  • The font becomes available in the library.
  • No errors in console or server logs.

Use Fonts in Block Editor

  1. Create or edit a post/page.
  2. Add a block (e.g., Paragraph).
  3. Open Typography settings → Font Family.
  4. Select the uploaded font.

Expected:

  • Font appears in the dropdown.
  • Font applied correctly in editor preview.

Frontend Rendering Check

  1. Publish/update the post.
  2. View on frontend.

Expected:

  • The selected font displays correctly.
  • No fallback or styling conflicts.

Responsive editing mode

The Responsive Editing Mode introduces enhanced control over how content appears across different device sizes directly within the block editor. This feature allows users to selectively hide blocks based on screen type — desktop, tablet, or mobile — helping create more tailored and optimized viewing experiences without requiring custom CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. or theme-level adjustments.

With this capability, site owners and content creators can better manage responsive layouts, ensuring that specific content elements display appropriately depending on the user’s device. This is especially useful for optimizing readability, improving mobile usability, and delivering cleaner layouts across varying screen sizes.

Testing Steps 

  1. Go to the WordPress dashboard and click on Page/Post.
  2. Open the page where you want to modify block visibility.
  3. Click on the specific block that you want to hide for a particular screen size.
  4. Click the three dots (⋮) icon in the block toolbar to open additional options.
  5. From the dropdown menu, choose the Hide option.
  6. Select the device type (Desktop, Tablet, or Mobile) where the block should be hidden, then save the page.
  7. View the page on the frontend and confirm that the block is hidden on the selected screen size.
  8. Verify Using List View
    • Click the List View icon in the top toolbar.
    • Locate the block in the list.
    • A crossed eye icon will indicate that the block is hidden on one or more devices.
  9. Modify Hide Settings (If Needed)
    • Click the block with the crossed eye icon.
    • The Hide Block Settings panel will open, allowing you to review or adjust visibility preferences.

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

New Admin Improvements

WordPress 7.0 includes a visual refresh of the admin interface aimed at modernizing wp-admin, improving consistency with the block editor design system, and enhancing overall usability. This update focuses primarily on styling and UI polish without major functional changes, so testing should emphasize visual consistency, plugin compatibility, accessibility, and regression checks.

Testing Steps 

  1. Review major admin screens such as Dashboard, Posts/Pages list, editor screens, Settings, Media Library, and Plugins/Themes pages to check visual consistency, spacing, typography, button alignment, and notice styling.
  2. Test plugin compatibility by activating commonly used plugins (e.g., WooCommerce, SEO plugins, form plugins, or custom admin plugins) and verify that admin layouts, buttons, tables, and forms display correctly.
  3. Verify core workflows like creating/editing posts or pages, uploading media, updating settings, and navigating across admin sections to ensure no functional regressions.
  4. Perform accessibility checks, including colour contrast, keyboard navigation, focus states, readability, and screen reader behaviour.
  5. Test responsive admin behaviour by resizing the browser or testing on tablet/mobile widths, ensuring menu collapse, tables, and buttons remain usable.
  6. Observe performance aspects such as admin page load time, layout shifts, console errors, or unusual delays.
  7. Conduct regression checks by comparing behaviour with previous WordPress versions to confirm workflows, settings, and media functionality remain stable.
    (Tip: Open a new Playground instance with an older version of WordPress, like 6.9 and compare )
  8. Report any issues such as broken layouts, plugin conflicts, accessibility regressions, inconsistent styling, or performance concerns.

Follow #64470 for more details.

Customizable overlay for the navigation block

WordPress 7.0 introduces Customizable Navigation Overlays, a new feature that provides greater control over mobile navigation menus directly within the block editor. Previously, mobile menu overlays offered limited customization options, often restricting users to default layouts and styling.

With this enhancement, users can design fully customized navigation overlays using blocks and patterns — allowing them to add branding elements, calls-to-action, images, and tailored navigation structures. These overlays are saved as reusable template parts, enabling consistent design across themes while also allowing theme authors to provide predefined overlay designs.

Testing Steps

  1. Insert a Navigation block on a Template.
  2. Select the Navigation block and look for the ‘Settings’ inside the right panel.
  3. Look for the ‘Overlay’ customisation controls and create a ‘Custom Overlay’.
  4. Preview it in the Editor.
  5. View it on the Frontend in mobile view.

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

Real-time Collaboration 

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

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

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

Testing steps

  • Install WordPress 7.0 Beta 1 on a server that somebody else can reach. 
  • This should probably be a new installation. maybe on a local network or on a staging server, or something in between—not a production server, but also not a local installLocal Install A local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer. on a single machine.
  • In the plugin, navigate to Settings > Writing and toggle on “Enable real-time collaboration.”
  • Open a post for editing. Start with a regular post, of course, but remember that pages are also posts, and custom post types are posts too! There are some exceptions, which you’ll find below. 
  • Invite a friend or colleague (or two or ten!) to edit the same post.
    • Consider joining a video call and sharing your screens so you can each see both experiences.
    • Or, collaborate with yourself! To do that, open your install in a separate tab and log in as someone else. See if you can edit as both people!
    • Another option: open your site on two machines on the same network.
  • If you have some, use real content—real text and images, other data sources and other media. See if you can use your usual workflows.

What to expect

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

What to notice

About overall functionality:

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

In real-life workflows, could you collaborate:

  • On custom blocks?
  • Inside a plugin’s UI?
  • In the site editor?
  • On a large document?
  • If you added more than one user?

How did RTC do on accessibility? Did it work:

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

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

New blocks & updates

WordPress 7.0 adds some new blocks:

  • Icon
  • Breadcrumbs 

The Icon block lets you add one or more icons and style them in limited ways, with more options to come in the future.

Testing steps

  1. Open a post or page.
  2. Insert the Icon block.
  3. Try out the options you see. 

The Breadcrumbs block ships with two options: to show the Home link and select the separator. For now, the block only works with hierarchical post types.

Testing steps

  1. Open a hierarchical post (like a page)
  2. Insert the Breadcrumbs block.
  3. Toggle the option to show the Home link. Does it show up on the page?
  4. Toggle the Home link off. How does that work?
  5. Experiment with choosing separator options. 
  6. Report your findings.

Plus, three blocks are getting updates:

  • The Gallery box adds a lightbox to switch between images.
  • The Cover block will support external video.
  • The Grid block is getting new controls.

Client side Media processing in the browser

WordPress 7.0 introduces Client-side media processing, leveraging the browser’s capabilities to handle tasks, like image resizing and compression, for smoother image processing. This enables the use of more advanced image formats and compression techniques, and reduces demand on the web server, providing a more efficient media handling process for both new and existing content, and supporting smoother media workflows.

With so many options and enhancements in WordPress 7.0 Beta 1, this is still only the beginning. You can expect future releases to be even better.

You can check the following details for clear and helpful test instructions.

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/preface.php Compatibility Update in WordPress 7.0 

WordPress 7.0 raises the minimum supported PHP version to 7.4, which means sites still running PHP 7.2 or 7.3 will not receive this major update and will remain on the 6.9 branch. To stay current and secure, site owners should plan to upgrade their PHP version with their hosting provider (ideally to PHP 8.3+) and test their site on staging before updating to WordPress 7.0. This change helps WordPress take advantage of newer PHP features and performance improvements while keeping support focused on actively maintained PHP branches; you can read more details in the official announcement here: 

Dropping support for PHP 7.2 and 7.3 – Make WordPress Core

What to Notice

While testing, keep an eye on:

  • Could you find all the features? Could you figure out how to use them just from the interface?
  • How did the workflows feel? Smooth and logical? Or were some slow, confusing, or broken?
  • Did you  notice visual regressions in the editor, admin screens, or frontend?
  • How did patterns, templates, and site editor changes behave when you changed style variations, or themes?
  • Did you test any assistive devices or on-device accessibility settings (focus order, keyboard traps, missing labels, reduced‑motion, contrast settings)? How did the feature work under those conditions?
  • Do you see PHP notices, warnings, or deprecations in logs or the debug console that weren’t there before? Did any show up on the front end, where visitors might see?

Make notes of anything that feels off—even if you’re not sure it’s a bug.

Where to Report Feedback

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

Choose any of these options:

  • Post in the #core-test & #core channel in the Making WordPress Slack to discuss issues in real time.
  • 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.0‑beta1 or 7.0‑RC1).
  • PHP version and database type/version.
  • Theme and active plugins.
  • Exact steps to reproduce the issue.
  • Screenshots, screen recordings, and any error messages/logs you could capture.

Changelog

1.0.0 – Initial Post

1.0.1 – Removed Tab Block Details

Props to @marybaum for working on the New Blocks and Real-time Collaboration sections.
Props to @anveshika for working on Customizable Overlay and Responsive Editing Mode sections.
Props to @amykamala, @muddassirnasim, and @wildworks for the pre-publish review of this post.

#release-field-guide

Image Nikunj Hatkar 4:36 am on February 20, 2026
Tags: ,   

X-post: WordPress 7.0 Beta 1 delayed

X-comment from +make.wordpress.org/core: Comment on WordPress 7.0 Beta 1 delayed

Image Ankit K Gupta 2:48 pm on February 17, 2026
Tags: , ,   

Test Scrub Schedule for WordPress 7.0

As you’re aware, WordPress 7.0 is slated to be the first major release of 2026, with the official release date set for April 9, 2026. As we gear up for this important milestone, our Test team will be shifting gears a bit. 

Starting from our upcoming weekly Patch Testing Session, we’ll be running a Test Scrub for WP 7.0 instead of the usual Future Milestone Tickets. These scrubs will focus specifically on tickets and issues related to the WordPress 7.0 milestone. It’s a great opportunity to contribute to this major releaseMajor 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. and make a tangible impact on the final product. 

Where Will It Happen?

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

What Tickets Will We Focus On?

We’ll primarily concentrate on tickets that are tagged Has Patch or/ Needs Testing for the 7.0 milestone. You can find these tickets in the 7.0 report on Trac. As the release moves through BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. and RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge., we’ll also highlight key features and regressions that need focused testing.

Interested in Leading a Test Scrub?

Did you know that anyone can lead a Test Scrub at any time? Yes, that means you can!

If you’re interested in leading a scrub, please reach out in the #core-test Slack channel with: 

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

If you’re planning a scrub that’s specifically focused on WordPress 7.0, that’s fantastic! We can add it to our schedule so the rest of the team knows to join in. Leading a scrub is a great way to contribute. 

Let’s Contribute Together

This is a perfect chance to get involved with the major release of WordPress 7.0, learn more about the release process, and help ensure the quality and stability of WordPress. Your contributions will make a difference, so join us for the Test Scrub sessions and be a part of this exciting release. 

Thank You ❤️

Thanks to everyone contributing time, testing, feedback, and expertise. Community testing plays a critical role in making each WordPress release successful.

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

Props to @huzaifaalmesbah, @marybaum, and @nikunj8866 for pre-publish review.

#call-for-testing, #core

Image Huzaifa Al Mesbah 5:11 pm on February 14, 2026
Tags: ,   

Test Chat Summary: 12th February, 2026

On Thursday, 12th February 2026 at 15:00 GMT, <test-chat> started in #core-test facilitated by @huzaifaalmesbah. The agenda can be found here.

1. Attendance

In attendance was: @ozgursar @mehrazmorshed @juanmaguitar @r1k0 @andrewssanya @mohkatz @noruzzaman @nikunj8866 (async)

2. Volunteer

This week’s facilitator was @huzaifaalmesbah

This week’s Note-taker was @huzaifaalmesbah

3. Test Team Discussions

Daily / Bi-Daily Testing Workflow Notice Proposal

@sajib1223 proposed adding a daily or bi-daily workflow notice to highlight tickets that need testing, include a quick-start guide, and possibly share weekly testing stats. The goal is to keep testing active, attract new contributors, and remind existing contributors.

@ozgursar asked how this would be automated. @huzaifaalmesbah suggested implementing it similar to the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ “Needs Testing” announcer and later mentioned that he liked the idea and found it helpful.

@huzaifaalmesbah also suggested that @sajib1223 create 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 Test Handbook repository so the broader Test Team can discuss and provide feedback.

@juanmaguitar proposed manually highlighting TRACTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets with the needs-testing keyword, especially non-bug tickets in the 7.0 milestone that should be prioritized before the upcoming 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 release.

Sync Weekly Meetings Section with the New CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Test Meeting Structure

The team discussed updating the Weekly Meetings section to align with the new Core Test meeting structure. @huzaifaalmesbah asked @mosescursor and @nikunj8866 to review the issue. @juanmaguitar offered to handle the update, mentioning that it only required editing page content.

@nikunj8866 confirmed that if JuanMa had the necessary access, he could proceed with updating the page. The update was completed by @juanmaguitar

Proposal – Restructure Test Handbook to Support Multiple Testing Domains

The team discussed the proposed project-based directory structure for the Test Handbook and next steps for implementation. Feedback was requested to help move the proposal forward.

@ozgursar shared that the new directory structure looks good and mentioned submitting a PR to add email testing instructions, which could fit into the new structure.

@juanmaguitar recommended avoiding duplicated information and instead linking to resources in other handbooks where possible.

@huzaifaalmesbah suggested first restructuring the Testing section under get-setup-for-testing, then placing email testing instructions in the most appropriate location.

The team agreed to continue the detailed discussion and feedback in the related GitHub issue before finalizing the structure and proceeding with updates.

4. Open Floor

During the Open Floor, @juanmaguitar highlighted a major feature planned for WordPress 7.0 the proposal to merge the WP AI Client into WordPress 7.0. He shared the related Trac ticket and noted that the post includes a “Call for Feedback and Testing,” encouraging contributors to review and provide feedback. He also reminded the team about the upcoming WP 7.0 Bug Scrub happening shortly after the meeting.

@huzaifaalmesbah thanked @juanmaguitar for surfacing the feature and asked about the WP Trac Triager Chrome extension created by @juanmaguitar — how it works and how it can support the Test Team.

@juanmaguitar explained that the extension enhances Trac ticket triage by surfacing key information in a clearer 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., including:

  • The latest comments
  • Milestone history
  • Keyword explanations
  • Component maintainers
  • Keyword change history
  • Quick links to comments

He shared that the tool is available on the Chrome Web Store and open to feedback via GitHub.

@ozgursar noted that the extension significantly improves Trac ticket triaging, especially for tickets with long discussion histories.

@huzaifaalmesbah added that the tool helps with quick navigation and makes it easier to identify reporters, committers, and maintainers at a glance. He expressed appreciation for the tool, highlighting that it helps the Test Team work more efficiently.

5. Announcements

WordPress Ecosystem Announcements

Test Team Announcements

Call for Testing

6. Other Meetings

Props to @bosskhj for reviewing this post

#core-test, #test-chat-summary

Image Huzaifa Al Mesbah 1:34 am on February 12, 2026
Tags: ,   

Test Team Chat Agenda: 12th February, 2026

Here is the agenda for the upcoming Test Team Chat scheduled for Thursday, 12th February 2026 at 15:00 GMT, which is held in the #core-test Slack channel. Lurkers welcome!

Agenda

#core-test, #test-chat-agenda