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.
📅 Mark your calendars! WordPress 6.9 is scheduled for release on December 2, 2025. As the final 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 2025, 6.9 will deliver key improvements to site editing, new developer tools, and performance refinements, all aimed at making WordPress more powerful and delightful to use.
Why test early? The sooner bugs are caught, the smoother the upgrade will be for millions of users. Whether you can spare five minutes or an afternoon, your efforts in testing 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. builds make a direct impact. Every report helps polish WordPress before launch, and every contribution makes a difference!
Release focus: WordPress 6.9 turns its attention to more intuitive template management, enabling collaborative content creation through notes(formerly “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. level comment” / inline comments), new blocks, extending developer capabilities with updates to the Interactivity 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. and the introduction of the Abilities API, and improving performance with faster page transitions and smarter resource handling.
📝 Notably, there will not be a new default theme in 6.9; a decision shaped by the pace of this release and the maturity of block themes over recent years.
Testing Tips
WordPress doesn’t require you to be a certified software tester or professional QA to contribute to testing. Simply use WordPress as you normally would for your own needs. If you encounter any issues or feel that something isn’t working as expected, you can 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 Beta/RC 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 usual. 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/rc version for testing purposes.
Use the General Checklist provided in the post below to verify everything functions as expected after the update. ✅
Ways to Test WordPress Beta Versions
There are multiple ways to test WordPress development or beta versions, as explained below. There is no right or wrong way; feel free to choose the method you are most comfortable with or that is most convenient for you.
Playground
Playground is the easiest and fastest 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.
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:
Install and activate the WordPress Beta Tester plugin.
Navigate to Tools > Beta Testing.
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 version:
wp core update --version=6.9-beta1 Or wp core update --version=6.9-RC1
(Keep updating the version number as needed.)
The Pros of this method are that it 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 or release candidate (RC) version. This allows you to safely test the new version without affecting your live site. Verify that everything functions as expected before applying the 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 – with 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. Simply 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 block 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 the functional part is working as expected, regardless of any 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.
👀 What to Notice While Testing?
Was everything intuitive and easy to use?
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?
Key Features to test
Notes
The Notes feature (formerly “block level comment” / inline comments) allows users to attach feedback directly to individual blocks in the editor. Initially introduced as an experiment in GutenbergGutenbergThe 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/ 19.6, it now includes indicators, a 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. for managing threads, and support for published posts, with ongoing refinements for usability and accessibility.
🌟Bonus point: Aki has built a plugin called Block Notes Data Generator. This plugin adds test users and test block comments to make it easier to test the Notes feature.
Test Steps
Navigate to Dashboard.
Open to page/post.
Insert any block.
Click on the block settings dropdown from the block toolbar.
Click the Add Note from the toolbar settings, and observe that the note modal is opening in the sidebar.
Add the note.
Confirm that the note is added successfully.
Verify the additional scenarios
Note on empty block: Notes should not be allowed on an empty block.
Editing and deleting notes:
Edit an existing note and confirm the changes are saved and displayed correctly.
Delete a note and ensure it’s removed from the sidebar and block indicator.
Resolve and Reopen the notes:
Resolve note: Confirm that when the note is marked as resolved, it shows the resolved state.
Reopen the resolved note (if the option exists) and confirm it restores correctly.
Threaded notes: Add a follow up reply to an existing note to confirm threading works properly.
Indicator visibility: Check that the note indicator appears only on blocks that have comments.
Switching blocks: Move focus to a block without notes and verify the sidebar updates accordingly.
Saving the post: Save or update the post and confirm that all notes persist after reload.
Published Post: Publish the post, and notes should remain accessible.
Accessibility: Navigate via keyboard and screen reader to verify the note sidebar and indicators are usable.
Testing Instructions
If you encounter any issues or unexpected behaviour while testing, please log them here. Follow #66377 for more details.
Expanded template management
A major improvement to template handling is coming in core. You can now duplicate templates, set which one is active, and disable theme templates while keeping your own versions. A new “Active templates” view makes it clear which templates are currently in use. This gives editors more flexibility and safer experimentation. Please check this separate Call for testing template changes for more insight and testing instructions.
Ability to hide the blocks
WordPress 6.9 introduces the option to hide individual blocks from the site’s public view while keeping them editable in the editor. This gives creators more flexibility when preparing content or layout. For example, testing alternate designs, saving space for future sections, or holding back pieces of content that aren’t finalised yet.
Unlike deleting or removing a block, hiding it is a non-destructive action: the block remains in place, can be edited at any time, and can be quickly shown again when needed. This approach makes content editing safer and better suited for collaborative workflows.
Test Steps
Navigate to the post, page, or template.
Select the block and click on the “Hide” control from the toolbar settings.
Observe that the block is no longer visible and the “Show” control should be toggled on.
Check the front, and the block should be hidden .
Now, turn off the hide setting.
The block should reappear in the editor and the front end.
Nested blocks: Place a few blocks inside a Group/Columns block and hide the parent.
Confirm that all inner blocks are hidden.
Multiple instances: Hide different blocks across the page and verify that only the chosen ones are excluded from the frontend.
Testing Instructions
Follow #71203 PR for more details. If you observe any related issues, please feel free to report them here.
📈Performance / Asset Check:
Hidden blocks should not appear on the frontend, and their related CSSCSSCSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site./JS should no longer be actively used. Optionally, you can verify this via the Network tab or CSS Coverage in DevTools. Visible blocks must continue loading normally. On small pages, coverage differences may be subtle; the key point is that hidden blocks do not add frontend markup or assets. Check #9213 PR for more details. If you like to verify the same, follow this comment for the steps.
allowedBlocks support & 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.
This enhancement enables users to visually control which child blocks can be inserted within a group block, something previously possible only through code. The update adds a Manage allowed blocks option in the Advanced panel of the block inspector, allowing users to enable or disable block types through a modal interface. This helps streamline content control, prevent unwanted block insertions, and sets the foundation for broader use across other container blocks.
Testing Steps
Navigate to Dashboard.
Open a Post/Page.
Insert a Group block.
With the Group block selected, open the block inspector.
Expand the Advanced panel of the Group block.
Locate the Manage allowed blocks button.
Click on it. Observe that a new modal appears listing different types of blocks.
In that modal:
Confirm you can search the blocks.
Deselect some blocks e.g. disable “Paragraph”, “Image”.
Click on the Apply button and the modal should be closed.
Now, Inside the Group block’s container area, attempt to insert child blocks:
Try to insert blocks that are allowed and they should appear and work properly.
Try to insert blocks that are disabled and they should not appear in the inserter.
Testing Instructions
If you observe any related issues, please feel free to report them here.
Command Palette everywhere
WordPress 6.9 introduces an expanded Command Palette, which is available across both the Editor and the Dashboard. It provides a fast, universal way to navigate different areas of your site and perform actions without relying on sidebar menus or multiple clicks. Simply type in the Command Palette to search, jump to specific screens, or trigger actions directly.
The Command Palette is enabled by default, so no additional configuration is required.
Test Steps
Navigate to Dashboard.
Open the Command Palette.
Use the keyboard shortcut (Cmd + K on Mac / Ctrl + K on Windows).
Confirm it opens regardless of which screen you’re on (Dashboard, Posts, Pages, Site Editor, Templates, etc.).
Various Use Cases
Search for Navigation Targets
Start typing e.g. “Posts”, “Pages”, “Plugins”, “Templates”.
Confirm you can directly navigate to those areas.
Trigger Actions
Type commands such as “Add new post”, “Add new page”, or “Editor”.
Confirm the action executes without going through sidebar navigation.
Context Awareness
From the Site Editor: check commands relevant to template editing.
From a post editing screen: check commands like “Preview in new tab”
Confirm results adapt based on any different context.
Role and Permission
The Administrator-only command should not appear in the search results for the Editor(other) role(s) to ensure the Command Palette respects WordPress capabilities/permissions filtering.
UI & Usability
Confirm the palette is responsive and visually consistent with other WordPress UI.
Testing Instructions
If you observe any related issues, please feel free to report them here.
Refining content creation
Drag and drop – Move block instead of drag chip
This enhancement replaces the “drag chip” (ghost placeholder) with direct movement of the actual block during drag-and-drop. While dragging, the actual block shrinks slightly (scaled down) and moves smoothly with your cursor, and animates while being dragged, providing a smoother, more intuitive visual experience.
Test Steps
Navigate to Dashboard.
Open a post/page.
Add a combination of Paragraph, Heading, Image, Quote block, etc.
Now, drag a block using its drag handle to a new position in the main editor canvas.
Release the block to a different position.
Observe that :
The block moves smoothly with animation.
While dragging the block gets slightly scalded down.
Visual styles and animation preserved.
No flicker or jump effect.
Verify Undo/Redo functionality after the block(s) move.
Verify that drag functions smoothly with nested blocks as well.
Testing Instructions
The goal is to create a more natural, accurate, and modern drag-and-drop experience, improving overall usability and aligning with WordPress’s effort to refine the editing flowFlowFlow 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.. Follow #67470 PR for more details, and if you notice any visual glitches, misalignment, or unexpected behaviour while dragging blocks, you are encouraged to report the issue with steps to reproduce here.
New Blocks
To broaden design possibilities and strengthen customisation options, WordPress 6.9 introduces several new blocks, such as Accordion, Terms Query, Stretchy Type, Math Block etc. These additions aim to give users richer ways to structure content and align layouts with modern design needs, making it easier to create expressive and flexible sites without relying on third-party solutions.
Accordion Block
The Accordion block allows users to organise content into collapsible sections, making it easier to present FAQs, lists, or grouped information compactly.
When added, the Accordion block creates two Accordion Items by default. Each item contains an Accordion Heading and an Accordion Panel where any block can be inserted. Users can add, remove, reorder, and style items, as well as nest different blocks within the content. On the frontend, items can be expanded or collapsed for interactive display.
Test Steps
Navigate to Post/Page
Insert an Accordion block
Confirm that the Accordion Item is added with an Accordion Heading and an Accordion Panel.
Edit item placeholders and add content inside the Accordion Panel
Save and confirm items expand/collapse as expected
Verify Reordering
Move Accordion Items up or down.
Confirm the order updates correctly in both the editor and the frontend.
Confirm styles are reflected in all items consistently.
Verify the duplicate of the accordion block.
Remove an existing item and ensure the block continues to function as expected.
Testing Instructions
If you encounter any related issues, please report them here.
Terms Query Block
This new Terms Query Block is similar to the Query block, but for terms rather than posts. It is designed to contain a new Terms Template block, which holds inner blocks with term data for displaying each term. Unlike the simpler Terms List block, it enables advanced layouts, nested content, and dynamic term rendering.
Term Name Block
This block is mainly developed for use in the Terms Query block to display the term name and allows for more layout flexibility. This also provides an option to add a link to the term.
Term Count Block
This block is primarily for use in the Terms Query block to display the term count.
Test Steps
Navigate to Dashboard.
Insert the Terms Query block in a template.
Observe Term Name and Term count are added by default.
Verify that the inspector controls render correctly.
Configure different taxonomyTaxonomyA taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. selections (E.g. Categories, tags, custom taxonomy)
Terms Query
Verify that the Make term name a link setting is present and works as expected.
Term Count
Verify that the correct term count is displayed.
Verify that you can change the bracket type.
Make sure the count and bracket type show in the editor and on the front end.
Ensure the template can be saved successfully with the block.
Verify the additional scenarios to ensure it works as expected.
Test Nested Layouts.
Test empty terms toggle.
Test different styling options for both Term Name and Term Count.
Testing Instructions
If you encounter any related issues, please report them here.
Math Block with Inline Math format
WordPress 6.9 introduces native math support through a new Math block and inline math format. This feature lets users add accessible mathematical formulas either as standalone blocks or embedded within text. Formulas are stored in MathML for better accessibility and compatibility, while preserving the original LaTeX input for easy editing. It provides a built-in solution for educational or technical content without needing third-party plugins. Although it slightly increases the editor’s bundle size, it greatly improves flexibility and accessibility for authors working with mathematical expressions.
Testing Steps
Navigate to Dashboard.
Open a Page/Post.
Add a new Math block.
Type the LaTeX-style expression: \frac{d}{dx}(x^3 + 2x^2 - 5x + 7) and click outside the block.
Observe: the editor should render the expression as a formatted formula. Also, the front end should render the formula correctly.
Try editing the expression with a new one and confirm that it renders correctly both in the editor and the front end.
Verify Inline math rich-text format
In the same post, insert a Paragraph block.
Type: The Euler identity is then apply the inline math format (select the inline math option from the format toolbar) and enter e^{i\pi} + 1 = 0.
Click outside to confirm inline rendering within the sentence.
Save and preview on the front-end. Confirm the inline math displays in-line and does not break the surrounding text flow.
Testing Instructions
If you find any issues while testing, please report them here.
Paragraph and Heading blocks with Fit Text
The Paragraph and Heading blocks now support Fit Text, enabling text to dynamically scale and fit within its container. This provides a flexible way to create attention-grabbing headings or stylized paragraphs without manually adjusting font size.
Test Steps
Navigate to Dashboard.
Open the Page/Post.
Insert a Paragraph block.
From the Inspector settings, tap on the Typography panel.
Confirm that a Fit Text toggle or control is available.
Enable Fit Text and add some text in the block.
Observe that the text automatically resizes to fill the available width of the container.
Resize the browser window or adjust the block width and verify that the text continues to adapt dynamically.
Repeat the same steps for a Heading block and confirm identical behavior.
Also confirm that on the front end text scaling persists correctly.
Testing Instructions
If you find any issues while testing, please report them here.
Time to read block
The time to read block was first introduced with the Gutenberg 15.3 release, and this block is now stabilised. This stabilization ensures that the Time to Read block behaves predictably in both the editor and the frontend, providing a reliable estimated reading time for posts and pages.
Test Steps
Navigate to Dashboard.
Add a new Page/Post.
Insert Time to read block.
Observe that the time is displayed as a range by default.
Confirm that you can switch between a time block, a word count block using the settings provided in the sidebar.
Preview or publish the post.
Confirm that the same value appears on the frontend.
Verify Updates When Editing:
Add or remove paragraphs.
Watch as the block updates in real-time.
Save and reload the editor.
The displayed time/words updates dynamically when content changes and remains accurate after reload.
Testing Instructions
If you find any issues while testing this new block, report them here.
Border radius size presets
WordPress 6.9 introduces border radius size presets (added in Gutenberg 21.5), a theme tool that lets developers define a set of named radius values that users can apply to blocks supporting border radius.
This feature enables theme authors to define reusable border-radius presets via theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., which show up in the block editor and can be applied per corner. Be aware of the notable limitation stated in the blog post. Check this ticket for more details about the same.
Social Links: Custom Icon extensibility
This enhancement allows developers to register custom social icons in the Social Icons block using block variations. Previously, adding custom social icons required custom code or third-party plugins. With WordPress 6.9:
Developers can easily register new social icons like Ko-fi, IMDb, Letterboxd, Signal, YouTube Music, Dropbox, etc.
Users can select and display these custom icons in the Social Icons block.
This reduces the effort of writing custom blocks or relying on plugins while ensuring consistent styling and behaviour across icons.
Register the custom Social Link variation. Follow this article.
Create a post.
Add Social Links and your custom variation that you registered.
Save the post and preview it.
Confirm that the custom variation is rendered correctly both in the editor and in the front end.
Testing Instructions
If you observe any related issues, please feel free to report them here
Developer updates
Updates to DataViews and DataForm
Updates to the DataViews and DataForm components include new field types and new 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. operators.
While these are foundational changes that do not expose specific breaking changes, they may have impacted screens that already use these components, specifically the Site Editor’s Pages, Patterns, and Templates screens. If you test the functionality of these screens and encounter any issues, please log them to the Gutenberg repository. It will also be helpful to link them to the DataViews & DataForm iteration for WordPress 6.9 tracking issue.
Introducing the Abilities API
The Abilities API provides a registry of callable Abilities with defined descriptions, inputs, and outputs. It’s designed to make WordPress functionality accessible to AI systems, particularly developers alike, through a unified registry of resources. As this is a developer API, testing can be done using a custom plugin like this one: https://github.com/wptrainingteam/wp-abilities-test.
Test Steps
Test Custom Abilities in 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.
Create a custom ability using wp_register_ability (docs)
Fetch all registered abilities using wp_get_abilities (docs)
Fetching a custom ability using wp_get_ability (docs)
Execute the custom ability using the ability’s execute method (docs)
For testers who use Postman, here is a Postman collection that can be used for local testing. Replace the {{baseURL}} variable in the request URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org field with the URL of your local WordPress installation, and the {{applicationUsername}} and {{applicationPassword}} variables in the Authorization tab with your username and application password.
core/get-bloginfo – Retrieve individual site information fields
core/get-current-user-info – Get current authenticated user data
core/get-environment-type – Get WordPress environment type
Test listing, fetching, and executing the three core abilities in PHP (docs) and using the REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. (docs).
This update enhances Interactivity API client-side navigation with a new stylesheet manager, a script module manager supporting multiple importmaps, and restored full-page navigation sharing logic with region-based nav. It also fixes missing styles during navigation between pages with different blocks.
Testing Instructions
In the site editor, go to the home template.
Ensure the “Force page reload” setting is disabled in the Query block.
Add an image block inside the Post Template.
Change its style and make the image rounded.
Visit a page of the home that doesn’t exist (e.g., page 2) so it shows the “No Results” block.
To test each of these updates, follow the testing instructions in each of the linked 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/ Pull Requests.
Updates to HTMLHTMLHTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. API
These updates include internal updates to HTML API as well as improvements to how WordPress Core handles and processes HTML, by implementing the HTML API.
This affects the following WordPress Core functions:
It is therefore useful to test these functions before and after the HTML API updates, to ensure they still work as expected.
WordPress 6.9 also includes a new WP_Block_Processor, which navigates through block markup in a similar way to how the WP_HTML_Tag_Processor navigates through HTML. See the related PR for the WP_Block_Processor class inline documentation.
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.
Following this year’s nominations and voting period, we are pleased to announce our new Test Team Reps for the 2025-2026 term! 🎉 Join us in welcoming Moses Cursor Ssebunya and Nikunj Hatkar to represent the Test team!
Moses Musoke Ssebunya is a WordPress professional with over six years of experience in development, testing, and community engagement. Since 2018, he has contributed as a developer, translator, and tester, and has led teams on various WordPress projects.
An active member of the WordPress Community Team, Moses has spoken at WordCamps in Masaka, Entebbe, and Nairobi, and organized local meetups in Uganda.
Moses is passionate about improving WordPress through testing and fostering collaboration across the community.
Nikunj is a WordPress developer with expertise in 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 development, 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. integrations, and web solutions.
An active contributor since 2024, he has participated in multiple WordPress teams and helped organize local meetups. Passionate about open-source, he enjoys problem-solving and sharing knowledge.
As a Test Team Representative, he wants to focus on improving WordPress quality, reporting bugs, testing releases, and supporting the community.
For several meetings, one of the topics that has been repeatedly coming back and forth is the idea of updating some Test Handbook pages, which have been stalling a bit for a fairly long time, and it’s good to keep them freshly updated with the last decisions that have been coming from the latest meetings, especially regarding certain topics like the new testing protocols.
Future-Proofing Docs Changes
It is important that we address this as soon as possible to keep our processes up to date and efficient. More specifically, in the last meeting, @krupajnanda commented that maybe we should be updating based on the Test Handbook GitHub repo. All current active Test Team members found value in this change and agreed on making it possible.
Furthermore, we could also agree that working in 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/ repo will let us have a perfect log of changes and reasons behind changes, plus having everything better documented than just making changes directly on the Test blog.
After taking a more in-depth look, it seems to be a great idea to start from that point, and from there, we will be taking the next steps to make this happen.
Working in GitHub also helps us share the responsibility of maintaining the team pages with other Test contributors, and not only the Test Team members locating issues and helping fix them.
Protocol to mirror the current docs with the tracker
First and foremost, we need to ensure that all existing documentation is accurately mirrored in the tracker to maintain consistency and track progress effectively. There was an attempt made 2 or 3 years ago, but the docs have changed partially, and not all the docs were fully mirrored back then. For the mirror sync to take place, all current docs in the blog must be removed first so they can be reloaded with the sync 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. We need to make sure with precision that the docs in the tracker are identical to the docs in the current handbook. We will have time to update them afterward, but first, the mirror should be as identical as possible. This task is not small and will take the following steps:
First, we need to check which docs remain the same.
Second, we have to add the missing docs with the best similar format possible.
Third, we must review all the assets (images, videos, etc.) and links.
Finally, we will have to make the table of contents manifest for the sync.
Collaboration and careful attention to detail will be essential throughout this process to ensure a smooth and accurate synchronization. A GitHub project will be created to track all the tasks in those four steps mentioned, assigned to each collaborator. Once we can confirm that the mirror is done, we can move into the next section.
Addressing Future Improvements to the Handbook
After the first step has been accomplished, we will need to execute the sync. For this process, @SirLouen will be contacting the MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team, and in collaboration with them, we will enable the sync process.
Once we have the syncing up, we will be able to handle improvements easily with the GitHub Issue Tracker. Making decisions on what to change and what not to will be an important factor in how to handle this. But ideally, we should continue with the current format:
Commenting on and addressing these things in our meetings
Proposing a PR
After some validations by the Test Team, they will be added to the Handbook.
Test contributors will have the ability to create GitHub PRs on issues in their time and convenience and to offer suggestions using GitHub Issues, and these are what will then be discussed in the meeting on a certain day or in a certain meeting to ensure proper planning and transparency. These issues will then be sorted by the Test team to see which ones meet the criteria.
Test Team members will have write access to the repository, so they will be able to accept revisionsRevisionsThe 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., but still, all changes should undergo a meeting process before approval. Proposals should go into either a GitHub issue or a GitHub PR and be brought into the meeting. This approach will help maintain clarity, ensure quality control, and keep everyone aligned on updates.
On the 4th and 18th of July, two feedback sessions were held with many contributors in the current Test Team. Valuable insights were gathered to shape a future to improve the overall Quality of CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. contributions. If you are here just for the steps to join, go straight to the bottom.
According to the last report, several key areas for improvement were identified, including a communication gap and the misguided efforts driven by this team. On top of that, the committer activity base has been significantly declining in the past few months. The gap between contributors and committing attempts has been increasing overtime without a clear solution upfront.
To address these challenges, the idea with the biggest consensus that has raised is the following: Developing a focused group with those Test Contributors looking to gather and share knowledge, a group open to anyone to join at anytime without seniority restrictions. This initiative is made to develop a way to fill that gap: Networking comes first, and Seniority comes next.
Vision & Mission
The vision of this project is to provide such a degree of quality that any committer could be so confident that the code has gone through enough quality checks that it could be ultimately merged blindly and fearlessly.
And the mission will be to guide contributors making concentrated efforts to build specialized talent and encourage networking with the rest of the team to polish their results over time.
Tackling the Hindrances: A Workflow Overview
Looking at the current simplified but flawed workflow:
Both Report Triaging (Bug Reproduction Report) and Patch Testing (Patch Testing Report) are the areas where historically the Test Team has been doing main efforts. But we have identified two main problems with this:
The triaging challenge
Reviewing and triaging a new ticket could feel the easiest task in this world: checking if what the user reports is happening and confirming in case all seems good.
However, this simplicity can lead to overlooking more in-depth issues or missing important details that might be relevant to the whole component.
For example, not being able to recognize if the ticket poses a real problem or if this is what’s expected for many reasons (like supporting backwards compatibility expectations).
Confirming that the issue is there, and tagging it subsequently as it Needs a Patch without enough perspective, is always leading to another contributor to take it blindly, and then making a patch on a report that is probably going to end being ditched for multiple reasons we did not consider. Without a top-level triage, we are wasting the efforts of contributors unnecessarily.
The testing dilemma
Most of the reasons were already explained here. But summarizing a bit, the main issue here is that most of the patches are not valid on a first attempt because the code provided could not be attending to similar concerns as stated in the triaging part: It could cause a backwards compatibility troubles or even a potential regression, code could be too repetitive, or too verbose, it could be poorly optimized, missing coding standards and further checks etc.
So testing these weak patches, without a code review, could be valid but not ideal and definitely insufficient for further progressing on a ticket. Testing should be done in a very late-stage and just like the last check that everything is perfectly in order, ready to commit.
Not only to mention that a lack of Unit Tests is one of the main elements that leads to a lower Quality Score (according to the Quality Report). No Playwright tests have been submitted in months, and most of 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. code commits don’t even have enough Test Coverage.
First Proposal
The proposal that has brought more attention to achieve a new level of Quality to the organization has been the idea of having contributors specializing in one single area or component within WordPress or GutenbergGutenbergThe 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/.
This approach aims to deepen expertise, improve efficiency, and enhance the overall quality of contributions within specific domains.
For example, contributors focusing exclusively on the Media component to identify and resolve issues more effectively, gaining knowledge, knowing their real limitations, and becoming an expert voice being able to discuss on the same level as any other more experienced generalist contributor.
Moreover, being able to achieve such a degree of knowledge could enable fluid and informal conversations with other members of the group when conflicts arise among different parts of the whole system and also, while a contributor’s self-confidence gets significantly boosted through the process more polished ideas will probably arise in the future.
Structure & Organization
The intention is to organize this group in a flat leadership structure, ensuring maximum autonomy and collaboration among the members. The mentorship figure could always be present, but the target is that each member becomes their mentor in his area to provide help on such and instruct and maybe introduce future generations.
Which are the Steps to Join and Participate?
Choose a Component in Core could you be willing to start with. Note: You can pick an area you are interested in to dive deeper, or a component you have successfully contributed to already. In the Gutenberg, we have still not decided any component subdivision because there are too many Blocks & Features (92 in total) so we might need a little more time to put more thought on how to regroup them to be more affordable and logical. But if Gutenberg is your way, and you want to put some effort into it as soon as possible, just open a new conversation and will start looking at it with thoughtfulness. Also, don’t be too mindful of the selection: there is no perfect component for you, and ideally choosing one that doesn’t overlap with another contributor is preferable than overthinking this.
Once you have selected a Component (or at least you are undecided with a handful of them), join the group on our weekly onboarding sessions (First session 25th of July @ 1PM GMT, and from there, every Thursday @ 1PM GMT, 3PM CET, 6.30 IST), or directly PMing any of the current members of the group.
As soon as we agree on where you are going to start, any current member will help you to get started and progress, to make your journey as comfortable and fun as possible.
Provide the feedback and share your experience with the group.
What to expect
Nothing here is written in stone. We will be adapting to everyone and to what actually works best. We will be in a learning process for long, and maybe, in 5 or 6 months, we might start to see the initial results when the group members start to reach that level we are talking about here. Mastering the whole WordPress codebase is an almost impossible task, but mastering on a full focus is very affordable, and we definitely have big expectations for all of you.
After six months of deep analysis inside the WordPress contribution ecosystem and for 3 months of intensive data collection (more specifically from the 6.8 release), a new light has been drawn over the current state of quality practices in the WP CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. project.
WordPress Test team has existed for ages, but for longer, it has always been perceived just as a group of people that simply performed some simple tests on tickets and patches just to triage and separate the wheat from the chaff.
From the start of 2025, as we have grown into a massive test team with more than 50 members, there is a firm decision to prioritize switching from bare testing to a more holistic approach on Quality Assurance, trying to observe all areas that might require attention and trying to find a way to fix them. This is the main reason of why this analysis report has been done.
Commits Data & Classification
Doing a completely manually curated analysis, checking each commit done individually from the release of 6.8 the 15th April until 6.8.2 the 15th of July here we have been able to classify Commits into some categories:
Improvement Commits, which include Bug fixes, Enhancements, Regressions, and New Features (no New Features though), fall into the same group. This is what we call improvement commits, and they need a more detailed analysis than the rest.
Chores, which are any type of task that doesn’t require a lot of in in-depth review, like Docs updates, Code Standards or any sort of automated issue discovery (like phpstan-based commits), Minor Unit Tests updates, version changes and all the other tasks that are mostly designed to maintain the project overall. Also, anything that relates to backporting
Special note about Bundled Themes component, for the whole analysis we have decided to exclude Themes because although it can have some testing, it’s very difficult to add any kind of automated testing so by default it will have a lesser Quality Score which could render results a little unfair compared to the rest of the areas. Maybe another quality specialized report specific for Bundled Themes could be done in the future.
With all this information in mind, here some facts and here is the data.
The commits done in this period sum a total of 217 units.
Total commits done by 17 unique committers.
Improvement commits were made by 14 unique committers.
From those 217 units, only 52 were Improvement Commits.
The total of Tests taken into those Improvements were only 29.
Quality Score Calculation Formula
The Quality Score is calculated based on the presence of automated tests, code reviews, and the amount of manual testing submitted before merging a commit. Each commit has assigned points for these three quality elements, and the total score reflects the overall quality assurance applied:
One point, up to two, per code review.
One point up to two, per manual test.
One extra point if it includes automated tests.
The maximum Quality Score per commit is a total of 5 points. This allowed an affordable classification and at the same time a way to compare results with activities that the Test Team are actually driving. Only commits from the improvements’ categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. were taken into analysis.
Classification for each commit is shown in the report as follows:
5 points: Outstanding
4 points: Excellent
3 points: Good
2 points: Needs Improvement
1 point: Poor
0 points: Unacceptable
Quality Score Facts
There were no commits with unacceptable level
Unfortunately, there were no commits with outstanding level.
The Average Quality Score for all Improvements is 2.47 out of 5.
Components by Commits
Only components with more than 3 commits show the average Quality Score, to have a minimal sample into account.
Media with 7 commits (3.29 Quality Score).
Build/Test Tools with 5 commits (2.4 Quality Score).
Editor with 4 commits (2.75 Quality Score).
Users with 4 commits (2 Quality Score).
Options/MetaMetaMeta 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. APIs with 3 commits (2.67 Quality Score).
Login and Registration with 3 commits (2.33 Quality Score).
Networks and Sites with 2 commits.
Administration with 2 commits.
Posts/Post Types with 2 commits.
Embeds with 2 commits.
And the rest, Query, Rest APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/., Toolbar, Bootstrap/Load, Site Health, Customize, RevisionsRevisionsThe 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., Upgrade/Install, Role/Capabilities, TaxonomyTaxonomyA taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies., Application Passwords, Comments, and Database, with only 1 commit
The other top-level components that did not receive a single commit were: Cache 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., Cron API, Date/Time, Export, External Libraries, Feeds, Filesystem API, Formatting, General, Help/About, HTMLHTMLHTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. API, HTTPHTTPHTTP 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. API, I18N, Import, Interactivity API, Mail, Permalinks, Plugins, Privacy, Script Loader, Security, Sitemaps, Themes, and XML-RPC.
Test Team Data
Using an LLM for data classification and with some additional double-checking, we have been able to retrieve a list of all the Test Reports performed by the Test Team from the release of 6.8 to the release of 6.8.2. This sum a total of 366 reports made by a total of 58 unique testing contributors. Here is the data.
!!! If I have missed someone in the list, please pingPingThe act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me and I will update it asap.
Data Analysis
The data suggests there’s a massive chasm between the efforts of the Test team and the extent to which those efforts are being utilised by the Core team. Only around 8% of the test reports appear to be reflected in commits, and nearly 60% of reports seem to be merged without any accompanying manual testing.
This gap highlights a significant underutilization of the Test team’s efforts, and this is what intuitively brought the attention of the Test Team for several months until it was decided to generate such a report with real data to confirm the concerns.
Finally, we can see, that only 8 committers out of 87 committers currently in this list, did more than 3 commits in a 3-month period, showing that barely the 9% of the committer base is active in Core nowadays. Despite the fact that some of them are very active in the GutenbergGutenbergThe 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/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 repository, we are only analysing the status of Core in this report.
Future Directions
This report calls for prompt attention to bridge the communication gap and better integrate testing efforts into the development workflow, given the extremely low resources that we count in Core nowadays.
Test team, on the opposite, has demonstrated to have enough capacity to provide results and, at the same time, but without some sort of guidance it seems that all efforts are being misdirected and, unfortunately, are providing minimal to no value. A poor communication line exists between Core and Test teams, and this translates to this disconnection we have found in the present analysis.
We recommend staying tuned to this blog because new projects will arise soon trying to help target the right aspects to improve the overall quality of the project, but at the same time, the Test Team will need to discover a simple way to open a communication channel with Core and find out which are the exact priorities that should be undertaken in every moment.
Here is where, if any Core Team member is reading this, please write your thoughts in the comments, and we will be grateful to read through them and work on consolidating all ideas.
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
You must be logged in to post a comment.