Gutenberg Core Sync Guidelines Are Now Written Down

Every WordPress release I have ever shipped has had the same hidden tax. Somewhere in the cycle, a piece of editor work that landed cleanly in Gutenberg the plugin showed up in core a beta later, with a slightly different build, slightly different dependencies, and a quiet bug nobody could reproduce locally. For years we wrote that off as “the price of two repositories.” It is not free. It eats committer time, it eats beta-tester goodwill, and it is the reason a fix you reviewed last month sometimes does not behave the same way in WordPress trunk.

So when Make/Core publishes a written, named, dated set of rules for how Gutenberg code is supposed to flow into wordpress-develop — with a cadence, a checklist, a commit-message template, and an explicit list of which hash values are allowed — that matters. Not because it is glamorous. Because it makes the boring part of WordPress predictable, and predictable is what an agency actually sells.

Here is what changed, why the change exists, and how I would adjust the way I read core commits going forward.

What is actually new

On June 30, 2026, Jonathan Desrosiers published Guidelines for Syncing Code From Gutenberg Into WordPress Develop on Make/Core. The post is the first formal, written process for how Gutenberg’s npm packages and built assets land in WordPress trunk. Until now, the answer was institutional knowledge held by a handful of committers — useful if you were in the room, opaque if you were not.

The mechanical change underneath the policy is already in: the way code maintained in the Gutenberg repository is imported into wordpress-develop moved from published npm packages to downloading a zip of built assets from the GitHub Container Registry, produced by the build-plugin-zip.yml workflow. Two bugs were blocking that pipeline; after fixes in changesets 62577–62578 and 62580–62584, WordPress trunk is now in sync with the most recent Gutenberg release, 23.4.0.

The cadence is the headline. During the alpha period — the long stretch between one final release and the next beta — “syncing will happen one week after each general release of Gutenberg.” The stated long-term goal is to eventually sync weekly, or even daily. After Beta 1, trunk pins to the corresponding wp/X.Y branch in Gutenberg via a gutenberg.sha value in package.json, which keeps unintended features out of WordPress while still letting cherry-picked fixes in. Syncs happen before every beta and RC. After SVN branching, the numbered branch stays pinned to wp/X.Y, and trunk bumps to X.Y+1-alpha and resyncs to the latest Gutenberg release in two distinct commits — one for the version bump, one documenting synced changes.

For minor releases the workflow is the existing trac dance — commit to trunk, mark the ticket with fixed-major and commit dev-feedback, merge after a second sign-off with commit dev-reviewed — with one new allowance: commits that change pinned SHA values on numbered branches are allowed provided the double-signoff process is followed. Only full-length SHA values are permitted in the gutenberg.sha field, even though release tags, wp-X.Y tags, PR tags, and trunk are all valid reference types in the underlying tooling. The reason is idempotency: only immutable references guarantee that a checkout today and a checkout in six months produce the same code.

The post also locks in a new ticketing convention. Each non-build-script change still gets its own Trac ticket (existing practice). Each alpha-period hash bump now gets its own ticket (new). Beta/RC hash bumps get a single rollup ticket per phase — “Gutenberg Syncs for Beta 2” rather than one per commit (new). Commit messages follow a template with the component, the hash range, a GitHub link to the diff, a bulleted list of included commits with PR links, follow-up references, reviewer credit, props, and the ticket reference. There is even a one-liner git log incantation in the post for generating the change list.

For broader context, this resolves something the Core Committers meeting at WordCamp Europe 2026 on June 5 flagged as live friction — the gap between SVN and Git working trees that Trac #64971 tracks, and the wider conversation about how to move faster without breaking the stable-release contract WordPress has been keeping since 2003.

Why it matters for WordPress and WooCommerce people

If you are a site owner, this looks like inside baseball. It is not. The sync cadence is what determines whether a Gutenberg fix you saw celebrated on X six weeks ago has actually reached the WordPress release you upgrade your client to. Until last week, the honest answer to “when does this Gutenberg PR ship in core?” was “ask a committer.” Now the answer is “one week after the next Gutenberg final, or right before the next beta or RC if the current cycle is past Beta 1.” That is a real planning tool.

For agencies, the value is debuggability. When a regression hits a client site after a minor release, you can now point at a single rollup ticket — “Gutenberg Syncs for 7.1 RC2” — and see the exact hash range and the full PR list that came in with it. Before, you would chase changesets one at a time across two repositories and three branch naming schemes. Most of us did not chase. We waited for someone else to file the trac ticket. That is not a sustainable contributor model.

For plugin and theme authors, the practical signal is that beta and RC cutoffs are now real cutoffs. After Beta 1, trunk pins to wp/X.Y and only cherry-picked fixes get in. If you wanted a Gutenberg feature in the August 19 WordPress 7.1 release, the time to land it in Gutenberg’s wp/7.1 branch is already running short. Anything that misses that window does not show up until 7.2 — and “I will catch it in the next sync” stops being a defense.

For WooCommerce-heavy work, the second-order effect is that the Gutenberg-side primitives WooCommerce 10.9 and 11.0 are betting on — the block-based Cart and Checkout, the Interactivity API store, the Add to Cart with Options block — get more predictable underlying behavior. A flakier Gutenberg-to-core sync was one of the quiet reasons block-based Woo had rougher edges than block-based content in the last two cycles. This is the kind of pipeline change that does not show up in a marketing post but shows up in fewer 2am Slack messages from clients.

What I would do (or not do) about it

If you ship to client sites: do nothing different this week, and start reading sync tickets next week. Subscribe to the Make/Core RSS or Slack, watch for the “Gutenberg Syncs for Beta 1” ticket when WordPress 7.1 Beta 1 lands on July 15, and skim the bulleted PR list. That five-minute habit is now the single best way to know what shipped between two beta releases. You used to need a committer’s brain to do that. You no longer do.

If you maintain a plugin or theme that hooks into editor internals: stop assuming a fix merged into Gutenberg trunk has reached WordPress trunk. Check the gutenberg.sha in package.json on the WordPress branch you are testing against, and check whether your fix’s commit is included in that range. The post even gives you the git log --reverse one-liner to generate the diff list. Use it before you file a “regression” bug against WordPress for something that has not actually been synced yet.

If you are a contributor with commit access or aspirations: read the post end to end, twice. Then read it a third time before you open a sync PR. The reviewer checklist is short — no new changes after running build:dev, changed files align with what the build script produces, WordPress works locally — but those three items catch the failure modes that have historically broken trunk for hours at a time.

What I would not do: I would not treat this as a one-and-done. The post explicitly lists future work — automating the sync ticket creation, updating the Core Handbook commit-message guidelines, revising the Branching Before Release documentation, updating the major and minor release checklists. This is the start of a process change, not the end of one. Expect refinements through the 7.1 cycle.

The boring infrastructure is what makes the interesting infrastructure possible. A Knowledge post type, an AI Client, a Notes feature, Real Time Collaboration — none of those land safely without a predictable pipeline underneath. Today WordPress finally wrote down the pipeline.