Testing Gutenberg Tickets with WordPress Playground

This guide focuses on the ticket testing workflow for GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ changes using WordPress Playground. The goal is to help contributors reproduce issues, verify fixes, and report results in a consistent format.

When to use Playground

Use Playground when a Gutenberg ticket can be tested in a browser-only WordPress environment.

Use a full local environment when testing depends on:

• Build tooling or custom scripts
• Complex server configuration
• Integration with external services
• Performance or browser automation testing

Finding tickets to test

A great place to start is the Needs Testing queue on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/. These are Gutenberg PRs that need a fresh set of eyes.

Prerequisites

Before testing, collect the following from the ticket or PR:

• Ticket/issue URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org
• GitHub PR number or PR URL (Gutenberg fixes ship as PRs; patch URLs are for WordPress TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets, not Gutenberg issues)
• Exact reproduction steps
• Expected behavior
• Any required preconditions (theme, post type, specific blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. settings, user role)

Then open Playground: https://playground.wordpress.net/

Test a Gutenberg PR in Playground

You can test a Gutenberg pull request directly in Playground using the gutenberg-pr query parameter. Playground builds and loads Gutenberg from that PR so you can reproduce the issue and verify the fix without a local checkout.

Example:

https://playground.wordpress.net/?gutenberg-pr=65337

Steps:

1. Open the PR on GitHub and note the PR number (the number in the PR title URL, for example 65337 in .../pull/65337).
2. Add it to the Playground URL: https://playground.wordpress.net/?gutenberg-pr=PR_NUMBER` (replacePR_NUMBER` with the number).
3. Open the URL in your browser.
4. Wait for the environment to finish loading; Gutenberg from that PR will be active.

Then:

• Reproduce the issue using the ticket steps.
• Confirm whether the PR resolves it and run your usual regression checks.

For a clear before-and-after, reproduce the issue first in a separate Playground tab without gutenberg-pr (for example default site plus Gutenberg from Plugins > Add New if you need the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.), then open a new tab with ?gutenberg-pr=PR_NUMBER and repeat the same steps.

For more options (WordPress version, blueprints, and other query parameters), see the Playground Query API.

Test against a Gutenberg branch (for example trunk)

To load a branch from the Gutenberg repository instead of a single PR, use gutenberg-branch. For example, to test the latest development line:

https://playground.wordpress.net/?gutenberg-branch=trunk

Use this when a ticket asks for verification against current Gutenberg rather than a specific PR.

Test workflow

1) Prepare a clean test environment

1. Open WordPress Playground in a new browser tab.
2. Install and activate the Gutenberg plugin from Plugins > Add New.
3. Confirm plugin and WordPress versions if the ticket depends on specific versions.
4. Configure any required preconditions from the ticket (for example: specific theme, block settings, or content state).

2) Reproduce the issue on baseline

1. Follow the ticket steps exactly before applying any fix.
2. Record what happens (actual behavior) and what should happen (expected behavior).
3. If you cannot reproduce, note where behavior diverges from the ticket steps.

3) Apply and test the proposed fix

1. For a Gutenberg PR, open Playground with ?gutenberg-pr=PR_NUMBER as described in Test a Gutenberg PR in Playground. For branch-based testing, use ?gutenberg-branch=BRANCH_NAME (for example trunk).
2. Repeat the same reproduction steps.
3. Confirm whether the expected behavior now occurs.

4) Run targeted regression checks

Check nearby editor behavior that could be affected by the change, such as:

• Related block controls
• Save and reload behavior
• Editor UIUI UI is an acronym for User Interface – the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. states (selected, focused, transformed)
• Frontend output (if relevant)

5) Report results

Add a short test report in the ticket or PR with:

• Environment used (WordPress Playground + Gutenberg active)
• Baseline result (before fix)
• After-fix result
• Regression checks performed
• Any follow-up observations

Suggested test report template

To stay consistent with existing handbook reporting style, use a format similar to the issue reproduction template and adapt headings for GitHub comments.

## Reproduction Report
This report validates whether the issue can be reproduced and whether the Gutenberg PR resolves it in Playground.

### Environment
- WordPress: Playground default (or specify if changed)
- Gutenberg source: `?gutenberg-pr=PR_NUMBER` or `?gutenberg-branch=BRANCH_NAME`
- Browser: <name and version>
- OS: <operating system>
- Additional details: <theme, plugins, settings, post type, user role>

### Baseline Results (Before PR)
- Steps followed:
  1. ...
  2. ...
- Actual result: ...
- Expected result: ...
- Reproduced: Yes/No

### Results After Applying PR
- Same steps repeated: Yes/No
- Result after PR: ...
- Issue resolved: Yes/No/Partially

### Regression Checks
- Checked: ...
- Result: ...

### Additional Notes
- Any follow-up details or edge cases.

### Supplemental Artifacts
- Screenshots/video: <links if available>

Example scenario

1. Open the linked ticket and copy the exact reproduction steps.
2. Reproduce the bug in Playground with Gutenberg active.
3. Save the baseline result (for example: control missing, incorrect transform, unexpected warning).
4. Open Playground with ?gutenberg-pr= and the PR number (or ?gutenberg-branch=trunk if the ticket calls for trunk), then repeat the exact steps.
5. Confirm the issue is resolved and validate one or two related editor flows for regressions.
6. Post the test report using the template above.