While the only actively supported version of WordPress is the most recent one, security updates are backported to older branches as a courtesy. All versions >=4.7 are in a security-only support state, receiving select security patches as a courtesy to users of WordPress.

The code maintained in the Gutenberg repository is just as critical to all WordPress versions >=5.0.

The code in the Gutenberg 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/ repository that corresponds to each release of WordPress is organized using wp/X.Y branches. These branches are frozen in time snapshots of the code that was used by wordpress-develop to build the final software that is released to the world. However, because the testing infrastructure in these branches has not been well maintained so automated checks and test suites are currently broken. Some fail consistently while others don’t run at all due to poorly scoped branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". filters, event targeting, and other issues.

It’s imperative that these GitHub 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/ Actions workflows and the underlying testing infrastructure is restored to a working state to ensure that all relevant security patches that affect Gutenberg can be properly validated and confirmed before being shipped to end users in WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

That’s where you come in!

Over the last few weeks I have worked with AI to create a pull request stack for each and every wp/x.y branch on the gutenberg repository that:

• Gets CI passing again, so changes to these branches are properly tested before they ship in a WordPress release.
• Modernizes and hardens the workflows by removing jobs that serve no purpose on a release branch, updating and pinning actions and runner images, and adding safeguards like job timeouts and workflow linting.
• Makes each branch’s test environment predictable by pinning it to the software versions that match its WordPress release, and testing the PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher and Node.js versions that release actually supports.
• Repairs the local development tooling (wp-env, Composer and PHPUnit), which broke as the outside services and packages it relies on changed over time.
• Stabilizes the test suites by fixing or backporting fixes for flaky and broken tests.

Some details about the approach:

• One fix per PR. Each stack has between 18 and 32 pull requests, and each one addresses a single, specific problem. Reviews come in small, targeted pieces instead of one large diff.
• Stacked PRs. Each PR is based on the one below it, so the stack reads from the bottom up. The Files changed tab on each PR shows only that PR’s change, and CI on the top PR tests the whole stack together.
• Same fix, same shape on every branch. A fix that applies to several branches has the same branch name (fix-actions-X.Y/<fix-name>) and a matching title on each of them. It also sits in roughly the same position in every stack. That makes it possible to review one fix across all branches at once, rather than reading through one branch’s entire stack.
• Only the branches that need it. Each fix was checked against each branch’s actual code, and a fix only appears where the problem exists. Where a branch differs, the PR adapts the fix to that branch.
• Following trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. where possible. Many fixes are backports or adaptations of changes already made on trunk, and those PRs link to the original PR or commit.
• No new package releases: Changes that would publish new versions of the repository’s npm packages are forbidden. The only exception is wp-env, a development-only tool that is not part of the WordPress code shipped to users, that a good portion of the testing infrastructure depends on to be operable.
• Documented and traceable. Every PR description explains what changed, why, and how, and cites the failing CI runs or error output it addresses. Each PR also links to a tracking issue for its branch.
• Human review: Any pull request related to this effort in draft state should be considered AI-produced and unverified by a human. I have staged each branch’s stack in my fork for testing and verification before pushing to WordPress/gutenberg. Each PR is then marked ready for review after a final confirmation.

Before this work can be merged, this needs to be reviewed and approved. With roughly 500 total pull requests across 20+ branches, your help is needed.

After discussing with a few contributors, it’s become clear that the best way to review each branch’s stack of pull requests properly is to divide them up by fix, not by individual stacks. This allows someone to review all of the PRs related to a specific fix as it relates to the code within each wp/X.Y branch without having to context switch through each and every problem in a stack.

While there is an overarching ticket Created for both bug reports and feature development on the bug tracker. for this project (GB-82780) and a sub-issue for each wp/X.Y branch, there are no issues for the individual fixes. To help divide and track the review efforts without overlap, I’ve created an issue for claiming and tracking the review efforts (GB-84853).

You’ll find a table on that issue that assigns each fix an alphabetical identifier and links to the corresponding pull request for each version branch. The first comment lists the branch name, a 1-2 sentence description, and any PRs that applied the same changes to trunk for each fix (if any).

Please use the following procedure if you’re able and interested to help in reviewing these pull requests:

• Comment on GB-84853 to claim a given fix.
• If you’re able, edit the table in the issue’s description to add yourself as the reviewer for that fix.
• When you claim a given fix, you are pledging that you will explicitly submit a review with an approval or a request for change on every PR in that row. An approving review is required for every PR in a given stack, otherwise the stack cannot be merged.
• Claim one row at a time. You can always claim another after you complete the first.
• If you are reviewing the PRs in a row and are unable to finish within 24 hours, please comment on the issue and (if able) and note in the Reviewer column of the table the branches that you reviewed. Example: “Needed: 6.0-5.7. (@desrosj reviewed 7.1-6.1)”

Anyone is welcome to help review these PRs. However, the rulesets configured on the gutenberg repository require at least one approving review from a member of the WordPress GitHub organization granted write access to the repository.

Currently only the wp/7.1 through wp/5.7 branches are ready and pushed to the gutenberg repository, but the rest will be added in the coming days. When new stacks are pushed and ready, a comment will be left on the issue to notify everyone who has helped out.

Restoring these workflows to a functional state is phase 1 of the necessary efforts to make these more maintainable long term. Once the workflows are functional in each wp/X.Y branch, a second effort will begin to adopt the reusable workflow pattern matching the strategy in wordpress-develop (see Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. #61213), which makes maintenance of these workflow files significantly easier because the functional logic being performed lives in trunk and is shared amongst all branches that perform a given type of testing or automation.

Thank you to everyone in advance for your help contributing to this effort!

Props @johnbillion, @jorbin, @lancewillett for pre-publish review.

#build-test-tools