The Test Team helps manage testing and triage across the WordPress ecosystem. They focus on user testing of the editing experience and WordPress dashboard, replicating and documenting bug reports, and supporting a culture of review and triage across the project.
Please drop by any time in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. with questions or to help out.
Category Archives: Highlight
SirLouen
7:22 am on May 15, 2025 Tags: good-practices, handbook, use-case
Testing for backend upgrades, refactors of code, and overall any new feature that cannot be “touched or seen” regularly feels very challenging for most WordPress developers.
Sometimes unit-testing can do part of the heavy lifting, especially when having expertise in TDD, as a great deliverable could be provided.
The problem with unit-tests is that sometimes they are completely biased to our thoughts and ideas. It’s extremely difficult to think outside the box (especially when you are absorbed into a development that takes most of our attention), and this could potentially leave behind some scenarios you have not considered testing.
Adding up, when finally code is delivered, including sometimes those unit-tests, the rest of the people who are going to review it will not have the full understanding of the problem, with all the nuances, edge cases, or scenarios that could pop out of your resulting code.
As a WordPress developer, you have to consider that other reviewers in the team could range from a coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. committer with 15 years of code to a brand-new testing contributor out of a WordCampWordCampWordCamps 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. willing to start lending a hand. And getting them to review if the unit tests are right, or even to review the code and add new unit-tests for more edge cases is, in numerous instances, even for the most experienced reviewers, a hard task and something to avoid.
Here is why a Testing Use-Case could become really handy for these scenarios, a paradigm of testing that could be easily learned and applied and would help further progress many reports with patches that have been stuck for ages.
Let’s dive into the Testing Use-Case
Ideally, from a Testing perspective, the best code refactor, patch, upgrade, or feature is the one that actually addresses a problem you are already having.
For example, as a patch creator, you can find any of these scenarios:
Have a theme or a pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that is missing this functionality.
Find a deprecation notice in the logs.
Find an error in code that requires not only a quick fix but a whole revamp of the code.
Have a real-life requirement by any real stakeholder in our business or life in general, and we can express the entire demand down to the last detail.
These are all examples of Testing-Use Cases
But what happens if you don’t have any of those? What if you are a code freestyler that likes to sort things before they actually happen? Or maybe you have been developing somewhere else and out of sudden you think about an alternative fix that could be improved, despite not really having a real-life example to showcase our idea?
Here is where building a Testing Use-Case becomes handy.
Ideas to Build Your Testing Use-Case
Not it’s time to put some examples of the most common issues that were found lately and how implementing a Testing Use-Cases could help to move forward the patch and overall any report that could potentially get stuck.
The Hook
One of the most common reports with troubles to be tested, and many end up in the “pending box” because of new HooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.. Most hooks come out of a specific need from a dev, but for some reason, many devs fear that explaining their use-case could feel “agendistic” and not usable by the majority. Also, it’s very common that there is almost always a workaround using outlandish PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. functions that bypass many standards and are not ideal by any means to achieve the same result as what a hook could provide us. So it’s very common that Hooks fade into oblivion.
Ideally, the #1 Testing Use-Case is, by far, explaining your business scenario without fearing any critique. Say you have a client that is paying you a big ticket, and you need that damned hook to get that attribute to do that selective filtering for the membership plugin you are building. This is totally fine if you need this hook for a commercial case. You can think that your case is unique and explanation will reveal it, but if you feel the need for this hook and there is no other straightforward way to achieve the same result without workarounds and hacks, it should be enough. Explaining the alternative solutions that were investigated will support your case. You may think that adding a hook to code is a simple thing, but when it is added, there will be no way to remove it or make changes that will break backwards compatibility, so the hook should be in the right place when it is definitely needed and have the right name and parameters. In addition, it should be documented in the code and in the Field guide and other documentation later. That one line of code requires a lot of support to happen.
Now to create the Testing Use-Case we have two options:
You can actually provide some of the code of that plugin you are building that showcases the feature where the new hook you are willing to implement is going to be applied.
If you would rather not showcase your code for copyright dilemmas with your client (funny in a GPLGPLGPL 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. environment, but we all know that this still happens), reproduce a minimal MVPMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia version of what you are willing to achieve, mocking some data or building a hydration function to fill whatever content is required to display the issue, and creating a very simple plugin that delivers that and uses that hook and executes successfully.
Choose whatever you prefer. But be aware that what is actually problematic is making your way through it without explaining much, without any testing at all, and despite the hook being super simple, straightforward, and unlikely to be problematic at all, this always leads to distrust and leans towards the forgotten zone where it will never be reviewed and integrated into the core. It’s always better to be transparent and clear of what needs to be done in a GPL environment, and in the worst case, discuss the feasibility and maybe a better clean code alternative if possible.
There is a rule in the WordPress community: never refactor if you don’t have a good reason for this. This is mainly because it takes many resources to test and debug issues coming from the refactor, and most code reviewers are busy enough just with the regular bugs to be fixed and pending improvements to be implemented to invest time in this protocol, so refactoring could be important but not as critical as other topics.
But very occasionally, there could a good reason for a code refactor, for example, an upcoming PHP deprecation.
In these cases, the best scenario, unfortunately, is waiting for the deprecation notice reports to appear, and start fixing from there, one by one. Bear in mind that deprecations take ages to be converted into unsupported features; hence, waiting is probably the best and easiest bet.
But what if you are a restless soul and like to have everything bleeding edge updated?
The following steps are recommended after the patch has been built (or before):
First, identify which core functions you have modified. If there are unit-tests already, you can edit them to cover your new code; otherwise you could always build them later.
Consider that the current function was working as-is with the current premise. You should start building a very simple plugin that uses this old premise with all the functions you modified, test them, and display the results.
After that, you will think about your new premise and again, in the same plugin, apply it once more to all the functions you modified.
Remember that both, before and after, you should be passing the test with the new premises. Yes, with a unit-test you are doing this. But, as it was commented in the beginning, unit-tests can become very convoluted (because they are not generally designed for simplicity, but for heavy-lifting the future-proof of the whole system). On the other side, a plugin can be elegant, simple, and easy to showcase all we want to test. Any coder, regardless of his coding level, will probably be able to inspect it, understand it, and maybe think in more edge cases based on what he sees. It’s a new paradigm of simplicity and support for your peer reviewers. And perhaps the difference between a lost into oblivion patch or a patch that will be reviewed comfortably and steadily. As a rule of thumb, it’s easier to port a test use-case plugin to unit-tests than the other way around.
This categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. is like a hodgepodge because here you could find very different examples, and it’s going to be very difficult to make a general assumption on how to always proceed. But some rule of thumb could apply here, similar to the two previous sections:
If you have a real use case, a feature required by your client, or a snippet of code that can prove your enhancement, this will be sufficient. You simply need something more than unit-tests, that again, can be biased. Something that can be replicated in the WP front-end or admin panel and be tested with real data, not just with the mock samples from the unit-testing framework. Finding any of these is going to be the ideal scenario for most cases.
If, for some reason in life, it happens that you have come to this enhancement almost out of nowhere, while reviewing some other thing or for whatever other reason, a plugin that proves the new feature is clearly needed. The steps are very similar to the previous section, “Code Refactors” but adapting to the potential new functions we have developed.
Finally, the crown’s jewel of backend patches. In fact, most devs in the performance team are relatively familiar with this; hence, not much to be explained here for them. But just some general ideas for those who are still not very familiar with this.
A performance upgrade must factually test that there is a performance upgrade. It’s not enough with “before this it took 2 seconds and not it takes 1.” Real data that could be deployedDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. in multiple computers, environments, etc. is required, and really show that there is a real performance improvement.
For this, you will need to write a plugin that does, at minimal, these two things:
A hydration system to generate X number of whatever we need to test. If a WP_Query with 10K posts should be tested, then a hydration plugin that actually creates those 10K dummy posts for us is required. If there is a plugin out there that works and does this, refer to it. Don’t suppose we all know it.
A plugin that, actually, makes use of those 10K posts and tests this performance improvement with functions like microtime and get_num_queries (including SAVEQUERIES)
This could feel pretty obvious, but these two parts are essential to building a Testing Use-Case for performance upgrades. And it’s still surprising the massive number of times that they cannot be found in the Performance tickets. Simply don’t expect anyone to write them for you. Take the lead and send it the whole pack by yourself: the patch + the plugin with performance tests. Otherwise, there is a big risk that the ticket ends forever in the forgotten box of unreleased patches.
More examples in the future will be provided as they become available because some categories, like the Back-End Enhancements and New Features, certainly need them.
If you have any comments, any questions, or any ideas to improve this guide on how to build your Testing Use-Case, please comment.
Props to @oglekler and @audrasjb for helping review this article and offering feedback
Welcome! Here’s a guide to help you join and participate in the Release Parties scheduled for WordPress 6.8. If you are new to attending a release party, this will help you get started.
This is where the release party happens! Use this link to join: #core channel
Arrive Early and Be Prepared:
Join the channel about 10 minutes before the scheduled time and make sure your test environment is ready to go.
Skip above steps if you already have WordPress Slack account and joined #core already.
Setting Up Your Test Environment:
Make sure you have a local development environment or testing site ready to run the latest WordPress 6.8 version.
(Please don’t test/update on any client site or any Production/Live Site)
Here are two methods to update to an RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge./BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. version:
Using WP-CLIWP-CLIWP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/https://make.wordpress.org/cli/: Ensure WP-CLI is installed on your environment. Run the following command to update:
wp core update --version=6.8-beta1
To verify the update with:
wp core version
Using the WordPress Beta Tester PluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party:
Install and activate the WordPress Beta Tester plugin:
Go to Plugins > Add New, search for “WordPress Beta Tester,” install, and activate.
Configure the settings:
After activation, go to Tools > Beta Testing in your WordPress dashboard.
You’ll see options to select the type of updates you want:
Bleeding Edge – Updates to the latest development version.
Beta/RC Only – Updates only to Beta and RC versions.
For testing an upcoming release candidateRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge., choose Beta/RC Only.
Go to Dashboard > Updates and update to the RC version.
What to Test During a Release Party:
When testing a WordPress release candidate (RC), the goal is to catch any issues or inconsistencies that could impact the final release. Here’s a checklist of key areas to focus on during testing: General Testing Checklist
You can also test anything you would like to ensure and provide your feedback.
Where to Provide the Status of Your Testing:
Main Channel: Provide updates directly in the #core channel on the WordPress Slack.
Format for Updates: Use a brief format to keep your updates clear and easy to follow:
What You Tested: Mention the specific feature you tested like creating a page with a coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience..
Results: Share whether the test passed or failed, along with any notable observations. Please look at the below scrshot for reference.
If test Passed: add
If any issues happen, add
Issue Details (if applicable): If you found a bug, provide a short description and any error messages, screenshots, or reproduction steps.
How to Update RC/Beta Via WP CLICLICommand Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. – Demo Video
For a step-by-step video guide on updating the RC version through WP CLI, watch this demo:
How to Update RC/Beta Via Beta Tester Plugin – Demo Video
If you prefer using the Beta Tester plugin, here’s a video guide to walk you through the process:
Previous Release Parties
If you looking to see what happens in Release Party, please checkout recent RC-2 Release Party here
Mark your calendars! WordPress 6.8 is set to launch on April 15, 2025. WordPress 6.8 will be the first major release of 2025 and will focus primarily on being a polished and bug-fix release. Get ready for a more refined and seamless WordPress experience than ever before!
Testing early means fewer surprises for users down the line! Whether you have a few minutes or a few hours, your help in catching bugs early during the release cycle ensures a smoother upgrade experience for millions of users after the stable release. Every contribution counts and is deeply appreciated.
WordPress doesn’t require you to be a certified software tester or professional QA to contribute to testing; use WordPress as you normally would for your own needs. If you encounter any issues or feel something isn’t working as expected, please report them.
Not sure about the expected behaviour? No worries! Join the conversation on WordPress Slack or create a ticket on Trac, where a helpful global WordPress community is always ready to assist.
Recommendations for Testing WordPress BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process./RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. Versions:
Test CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Features that Matter to You: Use your site for the purpose it was created. For instance, if you’re a blogger, running a social platform, or managing an e-commerce store, set up a staging site (ask your hosting provider if you’re unfamiliar with the staging site). Update WordPress in the staging environmentStaging EnvironmentA staging environment is a non-production copy of your site. This is a private place to build the site -- design, copy, and code -- until your client approves it for production or live. Sometimes used in addition to, or as a Development Environment., and continue using your site as you would daily. This will help you identify any issues that may affect your regular workflow. Take note of any issues or troubles you experience after the update. Do not test or update your live site with a beta version for testing purposes.
Use the General Checklist provided in the post below to verify that everything functions as expected after the update.
Ways to Test WordPress Beta Versions
There are multiple ways to test WordPress development or beta versions:
Playground
Playground is an easy and fast way to test beta or release candidateRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. versions of WordPress without setting up a full environment. You can quickly spin up a test environment using WordPress Playground.
Local Hosted Site
You can make use of software like Local or wp-env to create a local WordPress site. Once the site is ready, you can install the Beta Tester plugin to switch to the beta version of WordPress.
Once your site is up and running, you can use the WordPress Beta Tester pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to switch it to the development or beta version of WordPress. This plugin makes it easy to install pre-release versions of WordPress. To use the plugin:
Choose the Bleeding Edge or Point releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. with Nightlies option, depending on what you want to test.
Click on Save Changes
After the changes are saved, you should receive the update notification. Kindly update your WordPress version.
For more detailed instructions, follow this guide.
Via WP-CLIWP-CLIWP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/https://make.wordpress.org/cli/
If you prefer working with command-line tools, use WP-CLI to install a WordPress beta version quickly.
Steps:
Create a local WordPress site using your preferred method.
Once the site is set up, open your terminal and navigate to the root directory of your WordPress installation.
Run the following command to update to the latest beta/RC version:
wp core update --version=6.8-beta1
OR
wp core update --version=6.8-RC1
(Keep updating the version number as needed. E.g. –version=6.8-beta2)
This method helps you to switch between different versions quickly, making it easier to test specific builds.
Using a Staging Site
Create a staging site for your live production siteProduction SiteA production site is a live site online meant to be viewed by your visitors, as opposed to a site that is staged for development or testing. and update it to the WordPress beta/RC version. This lets you safely test the new version without impacting your live site. Make sure everything functions as expected before applying updates to your production environment.
Testing Patches
If you plan to test patches, follow these instructions to set up a WordPress development version locally.
Using Playground, you can also easily test individual Core tickets without installing any software in your system, and this is the fastest way to test any PRs.
If there is a specific PR in the wordpress-develop or gutenberg repo that you’d like to test in the browser, you can do so using the following links. Enter the PR number, and the rest will be taken care of.
If you want to quickly test the updated WordPress version’s compatibility with your site, please verify the following important checks. Enable debugging in wp-config.php to capture the warnings, errors or notices.
Update your theme and plugins to the latest versions.
Switch to the Beta/RC/Night build you want to test.
Check Site Health to see if there are any new errors or warnings.
Confirm there are no layout breaks or misaligned elements.
Test links and permalinks to ensure there are no 404 errors.
Verify that posts, images, and media are displayed correctly.
Ensure the sitemap and robots.txt files are functioning properly.
Ensure full access to the admin dashboard without errors.
If your site has custom blocks, create content in a new blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. and edit existing content.
Create a new post:
Add content
Copy-paste text
Manually add media files.
Save the post
Observe the console for any issues.
Create a new page:
Add content
Verify its display in different browsers.
Verify its display in responsive mode.
Verify that the functional part is working as expected regardless of browser or device type.
Keep the browser’s developer console open and check for any errors, warnings, or notices.
Open the error log file and check for notices, warnings, and fatal errors.
Review user roles and permissions to ensure they remain intact.
Verify that any scheduled posts or automated tasks (like backups) still function as intended.
Ensure all integrated services (like payment gateways or analytics) are operational.
Open your site in different browsers and verify that all functionalities work as expected.
Key Features to test
Editor
New default rendering mode for editor via post type supports
The GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ PR #69286 introduces a new approach to setting the default rendering mode in the WordPress block editor based on post-type support. This enhancement allows developers to define how content is rendered in the editor by specifying parameters within the support property of a post type.
Test Steps:
Install and activate any block theme. E.g 2025
Open a new page
Verify that it renders in a template-locked state.
Now, disable the “Show Template” in the sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. and reload the page.
Verify that it uses “post-only” as the default rendering mode.
Re-enable “Show Template” from the sidebar bar.
Open a post and confirm that it still renders in “post-only”.
Now, switch to a classic theme. E.g. 2011
Confirm that posts and pages both are loading correctly without showing the template.
Design Improvements
The design focus is refinement and fixing issues requiring design feedback. Let’s check them one by one.
Stylebook improvement for classic theme
The Style Book now provides a more structured layout, making it easier to preview and understand site colours, typography, and block styles.
Support is available for classic themes that either support editor styles via add_theme_support( 'editor-styles' ) or have a theme.json file. Each block example and style group is labelled for better clarity. For classic themes, the Style Book now supports site patterns, which have been relocated to Appearance > Design > Patterns for a more intuitive experience. Previously, patterns were listed under Appearance > Patterns.
Testing Instruction:
Please help identify potential issues and suggest areas for improvement by logging your feedback on #68036. Follow PR 66851 for more details about this fix.
Reset Button for Color Control
A new Reset button has been added to the colour control, allowing users to quickly revert the color changes.
Testing Instruction:
Test Steps:
Create a page and a paragraph block.
Add text/background/link colors to the paragraph.
Observe the change in the color.
Now, hover/focus on the element and observe the presence of the reset(-) button.
Clicking on the reset button resets the applied color.
If you encounter any issues or have suggestions, feel free to drop your feedback in this ticket #41866.
Zoom-Out Mode Enhancements
Users can now apply different section styles and designs directly from the toolbar.
Testing Instruction:
Test Steps:
Navigate to Appearance > Editor
Edit the page and choose the pattern.
Enter into zoom-out mode.
Observe the toolbar with a newly added icon.
Verify that there should be no shuffle button present and that the change design option should be visible.
Click on the icon, and it will change color based on the different styles.
Follow PR #67140 for a detailed understanding of the implementation path.
Improved Font Picker Previews
The font family list in Global Styles now previews each font directly in the dropdown. This provides a better visual indication of how the font will look before applying it. Testing Instruction:
The outcome of the Image manipulation method is now better communicated in the block editor. The success notices are now displayed at the bottom of the editor. The notices also come with a handy Undo link to revert to the original if necessary.
Testing Instruction:
Test Steps:
Create a post or page, insert the Image block and select an image.
Try different editing options for Image – edit, zoom, crop, rotate.
A correct message should be displayed after processing the media.
Also, confirm you can easily undo changes using the snack bar action.
Both these changes are part of different PRs #67314 and #67312
Block supports: Show selected item in font family select control. (#68254)
Fix: Ensure consistency in editor tools for navigation buttons and delete options. (#67253)
Global Styles: Fix handling of booleans when stabilizing block supports. (#67552)
Support for Speculative Loading
We are excited to announce that WordPress 6.8 includes native support for speculative loading, a feature designed to enhance site performance by enabling near-instant page load times.
What is Speculative Loading?
Speculative loading leverages the Speculation Rules API to automatically prefetch or prerender certain URLs on a page based on user interactions, such as hovering over a link. This proactive approach allows subsequent pages to load more quickly when users navigate to them.
Default Configuration
WordPress 6.8 configures the speculative loading feature by default to prefetch URLs with a conservative eagerness setting. This means the browser will prefetch resources only when there is a strong indication that the user intends to navigate to a particular link, balancing performance benefits with resource usage.
Testing Instruction: Customisation via Filters
While there are no options or user interface controls to modify the behaviour of speculative loading as we have in the Speculative loading plugin, developers do this by customising its functionality using the newly added filters with different combinations of values.
Please check this comment for a more detailed explanation of how to test.
Use a browser that supports the Speculation Rules APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (e.g., Chrome 108+, Edge 108+) because not every browser supports it. Please refer to caniuse.com for a comprehensive support overview of speculation rules.
Impact on Existing Plugins
With the integration of speculative loading into the WordPress core, the existing Speculative Loading plugin that provides similar functionality will be updated to use the core implementation. The plugin will continue to use its approach to prerender URLs with moderate eagerness, now by adjusting the default configuration set by Core.
We encourage developers and site administrators to test this new feature in their environments and provide feedback. Your insights are invaluable in ensuring that speculative loading enhances performance effectively across the diverse WordPress ecosystem.
Please check this ticket #62503 for more information about this enhancement. Feel free to comment and share your feedback/queries/issues regarding performance and speculative loading integration.
Polishing the Query LoopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop.
Fix: Sticky Posts Not Working with Default Query Type
Previously, sticky posts did not appear at the top when using the default query type in the editor. This issue has now been fixed.
Testing Instruction:
Test Step:
Have at least one sticky post on the blog
Open the template using the editor’s query loop block (index, archive, etc.).
Notice that the sticky post is at the top.
Open the front of the site and see the sticky post at the top.
Please refer to this #68570 ticket for more details about this fix.
“Ignore” Option for Sticky Posts
A new “Ignore” option for Sticky Posts has been added to the Query Loop block, giving users more control over including or excluding sticky posts in the query. It adds a new option for the Query block’s sticky post setting: “Ignore,” which doesn’t prepend sticky posts at the top but displays them in the natural order of the query.
Testing Instruction:
Test Steps:
Have at least one sticky post on the blog.
Create a page and add a simple Query block.
Confirm that the sticky post is displayed at the top by default.
Change the sticky post setting to “Ignore”.
Confirm that it’s now displayed in natural order.
If you find any issues while testing this enhancement, please feel free to share your findings here in issue #66221
Set Depth Limit for Query Loop
The Query Loop block retrieves posts from all levels, and there is no built-in option to filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. only top-level posts as they do not have a parent field that can be set to 0.
The current solution partially addresses the issue by allowing “parents”: [0] to be set programmatically but not providing a UIUIUI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. option. This PR includes an example Query markup for testing. As for the UI, the Parent filter will be updated once a suitable design proposal is available. Please share your feedback by commenting here on the issue #68620
Removal of Redundant Sticky State
The redundant sticky state in the Query Loop block has been removed for a more streamlined user experience.
Testing Instruction
Test Steps:
Insert a Query Loop and select a pattern with some posts.
Open the inspector controls of the block.
Verify that the Post Type field is working as expected:
The “Sticky Posts” field is visible when “Post Type” is “Post“
The “Sticky Posts” field is hidden when “Post Type” is “Page“
Query Total: Add interactivity.clientNavigation block support
With RC1 we have introduces the support for interactivity.clientNavigation within the Query Total block. This enhancement enables the Query Total block to interact seamlessly with client-side navigation, ensuring that the displayed total number of query results updates dynamically as users navigate through content without requiring the full page reloads.
Testing Instruction:
Test Steps:
Create a page
Add Query Loop block
Within the Query Loop, insert a Query Total block.
In the Query Loop block, toggle off “Reload full page” from right sidebar.
In the Query Total block, change display type to “Range display”.
Save the change and open the page in the front end
Observe that client navigation is now working as expected.
“Refining Data Views” allows the customisation and improvement of how data is displayed and managed within the WordPress editor, particularly by utilising the “Data Views” feature which allows users to filter, sort, and organise content more effectively through various options and settings, ultimately leading to a cleaner and more efficient workflow when working with large amounts of data on a website.
WordPress 6.8 release comes with additional improvements and fixes, as mentioned below.
Unify layout behaviour
This update aims to improve the user experience by providing a more intuitive interface. The implementation includes adjustments to the existing components to integrate the new media field seamlessly. This enhancement is part of the ongoing efforts, and to keep up with the progress, please check this issue #67391
Testing Instruction:
Test Steps:
Open the different data views for Pages, Templates, and Patterns
Check the design of the different layouts for List, Grid and Table
Check how the “properties” menu works with the different layout
Add confirm dialogue before delete
The existing ‘Permanently Delete’ action lacked clarity and did not include essential safeguards, such as a confirmation modal. This absence increased the risk of accidental deletions. To improve the user experience and minimize errors, this PR introduces a confirmation modal, ensuring users confirm their intent before deleting selected posts.
Testing Instruction:
Test Steps:
Go to the WordPress admin dashboard area.
Go to Appearance > Editors > Pages
Click on the page that you want to delete
The page will move to the TrashTrashTrash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days.
Now, select the trashed page and use the “Permanently Delete” option.
Confirm the deletion in the modal dialogue.
Observe the success or error notices appearing for both individual and bulk deletion options.
This PR #67170 introduces a density option to the table layout while allowing layouts to define specific controls. Instead of a generalized density abstraction, this approach ensures better clarity and avoids confusion for table layouts.
Testing Instruction
Test Steps
Go to the WordPress admin dashboard area.
Go to Appearance > Editors > Pages
Go to Pages/Templates/Patterns
Change the layout to Table View
Now, click on the settings icon
Observe the newly added Density option
Please play around with all three options, “Comfortable, Balanced, and Compact,” and share your feedback if you have it.
Use badge component in data view grids
This update improves consistency in the Site Editor by using a standardised badge for synced patterns. It ensures a uniform look while keeping the existing functionality unchanged. The new Badge component is integrated into the DataView grids to enhance consistency and maintainability.
Testing Instruction:
Testing Steps:
Navigate to the WordPress dashboard
Go to Appearance > Editors > Patterns
In the Patterns list, identify any patterns labelled as “synced”.
Confirm that these “synced” patterns display a badge utilizing the new Badge component, ensuring consistency in design and functionality.
Set Featured ImageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. directly from block
WP Core now has a new toggle set under the settings for the post. If a feature image is not set for the post, enabling the toggle control will set the selected image as the feature image for that post. Follow the steps mentioned below.
Testing Instruction
Test Steps:
Create a new post.
Add an image block.
Enable the “Set this image as featured image” toggle from the settings.
Verify that the selected image is set as the post’s featured image.
As the first step of running Interactivity API event listener callbacks asynchronously by default (see #64944), a utility function called withSyncEvent is introduced. Developers should use this function to wrap event handlers that require synchronous access to event data or methods, such as event.preventDefault(). For other event handlers that don’t need synchronous event data, the system can defer their execution, enhancing overall performance by reducing the load on the main thread.
Follow the testing instructions mentioned here in the description of PR #68097
Block HooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. API
The Block Hooks API is an extensibility mechanism that allows you to dynamically insert blocks into block themes. In WordPress 6.8, work will continue on improvements to Block Hooks.
This release also includes a fix for the Post ExcerptExcerptAn excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. block to display an extra “>” character at the beginning of the excerpt when no custom excerpt is set and the Query Loop block is added to a page. Additionally, for sticky posts without a custom excerpt, the beginning characters of the excerpt are missing.
Please follow the testing instructions mentioned here in issue #68903
We have also updated the document of the block hooks section of the block registration reference guide. Please check issue #65454 for more details on what has been updated.
Security enhancements
The underlying algorithm used to hash and store user passwords in the database has been changed in WordPress 6.8 from phpass portable hashing to bcrypt. Application passwords, user password reset keys, personal data request keys, and the recovery mode key will switch from using phpass to the cryptographically secure but fast BLAKE2b hashing algorithm via Sodium. The full details of this change can be found in the announcement post.
These changes should work and should be invisible to users. Passwords and security keys that were saved in prior versions of WordPress should continue to work after updating to 6.8. Users don’t need to change or reset their passwords; logged-in users should remain logged in, and their sessions should remain valid.
Here are some testing steps that can be taken:
Remaining logged in after the update
Ensure you have remained logged in to your account after updating to 6.8
Confirm that logging out and back in again works as expected
Confirm that the user_pass field for your user account in the wp_users table in the database has been updated — after logging out and back in again it should be prefixed with $wp$2y$ instead of $P$
Password resets
Start with the “Lost your password?” link on the login screen and initiate a password reset
Click the confirmation link sent to your email inbox
Follow the process of resetting your user password
Confirm you can log in with your new password
Personal data requests
Log in as an Administrator
Initiate a data export from Tools -> Export Personal Data
Click the confirmation link sent to the email address and confirm that the export gets triggered as expected
Remaining logged in after the update
Ensure you have remained logged in to your account after updating to 6.8
Confirm that logging out and back in again works as expected
Confirm that the user_pass field for your user account in the wp_users table in the database has been updated — after logging out and back in again, it should be prefixed with $wp$2y$ instead of $P$
Password resets
Start with the “Lost your password?” link on the login screen and initiate a password reset.
Click the confirmation link sent to your email inbox
Follow the process of resetting your user password
Confirm you can log in with your new password
Personal data requests
Log in as an Administrator
Initiate a data export from Tools -> Export Personal Data
Click the confirmation link sent to the email address and confirm that the export gets triggered as expected
Additional performance improvements
The additional performance improvements are also part of the WordPress 6.8 release, and details are provided in their respective issues/PRs, as explained below.
Did you notice any performance issues, such as slow loading or lag?
Were there any visual inconsistencies or layout issues across different browsers or devices?
Did the drag-and-drop functionality work as expected, especially in patterns?
Did the preview mode accurately reflect how the content appeared once published?
Did what you created in the editor match what you saw on your site?
Did you observe any other accessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) issues like –
Colour contrast or focus management?
Did it work properly using only a keyboard?
Did it work with a screen reader?
Did it function smoothly on a mobile device?
What aspects of the experience did you find confusing or frustrating?
What did you especially enjoy or appreciate?
What would have made site building and content creation easier?
Where to Report Feedback
If you find any issues but aren’t sure if it’s a bug or where best to report the problem, share them on the alpha/beta forums of WordPress. If you are confident that you found a bug in WordPress Alpha/Beta/RC, report it on Core Trac for rollback auto-updates and the Gutenberg GitHub repo for every other feature.
We are delighted to announce the publication of a new handbook page detailing the process for acquiring Test Team Profile Badges. The Test Team Badge serves as a recognition of your invaluable contributions to the WordPress testing team. Whether you’re an experienced tester or just beginning your journey with WordPress, these badges signify your commitment and expertise within the Test Team community.
You can find the new page added to the handbook section of Make WordPress Test site.
Test Contributor Badge
To earn the Test Contributor Badge, you must have completed one or more of the following tasks:
Submitted test reports for at least 1 ticket, comprising of testing instructions, issue reproduction, and/or patch testing. Acceptable reports should be submitted to TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. or GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, and can apply to any WordPress project area included in the Test Team duty of care.
Submitted unit or end-to-end tests that have been merged.
Contributed to a Test handbook PR that has been merged.
Participated in a Contributor Day as a Test table lead, providing technical support, or assisting with onboarding.
Suggested a thoughtful idea aimed at improving testing processes in any way, which gets implemented.
Test Team Badge
If you have served as a Test Team RepTeam RepA Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. or Test Lead in any major releaseMajor ReleaseA 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 WordPress, or have consistently made substantial contributions to the Test Team, you are eligible for the Test Team badge.
To request your badge, please follow the details available here.
Thank you for your dedication and commitment to making WordPress better for everyone. Your contributions are invaluable, and we look forward to celebrating your achievements with the Test Team Profile Badges!
Are you excited about the next big release in the WordPress world? The current target for the WordPress 6.5 release is March 26, 2024, which is less than a month away! Your help in testing 6.5 ensures everything in this release is the best it can be.
In addition to betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. and RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. testing with a handy tool like the WordPress Beta TesterpluginPluginA 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 requires a hosted or local development environment, did you know that you can test WordPress’s newest featuresusing only your browser? Let’s see how WordPress Playground makes this possible.
“Instant” Test Environment
It’s true! Launching a site with WordPress Playground makes getting set up for testing much easier. Here’s a shortcut to launch Playground running the latest WordPress pre-release, with Test Reports pre-installed to help with bug reports.
Use the menus in the top-right corner of a Playground instance to change the PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. version, load additional PHP extensions, and more.
After applying changes, the Playground will reload with your new configuration.
Let’s Test!
Now open up the Help Test WordPress 6.5 post and put 6.5 through its paces! You can easily test and experiment with the latest development version of WordPress.
In addition to testing the latest pre-release build, here are the things what to Test with Playground:
Check Site Health to see if there are already some issues that will be unrelated to the update.
Check for Errors, Warnings, and Notices.
Open the developer console in the browser.
Try to create a new post, add some content, and save it, especially try to copy and paste content from another source, add comments, add media files of different types, and do other usual actions in the admin. While doing it, pay attention to the information in the console to see if there are any issues.
Test in different languages.
Use just your keyboard to navigate, or use a screen reader.
Test with both blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. and classic themes.
If you want to create your own setup in Playground and save it for later use, export your configuration with the download/export button in the top-right corner of Playground. Use the upload/import link to restore a saved configuration in the future.
Have you tried Playground for testing yourself? Were there any WordPress features that you couldn’t test? Got any tips or tricks you learned on the way? Please share your feedback in the comments below.
You must be logged in to post a comment.