WordPress Core Committers Meeting at WCEU 2026: What Changed

I have been watching WordPress release cycles since the days when “trunk” was a place you SSH’d into at midnight. So when a recap of an in-person Core Committers meeting lands on the Make blog, I read it twice. The good ones tell you where the project is actually heading, not where the marketing decks say it is.

The recap that dropped yesterday from the Kraków meeting is one of the good ones. It is candid about how fragile the WordPress + Gutenberg coupling has become, honest about the real-time collaboration mess, and frank about the fact that almost nobody is testing betas before they ship to a hundred million sites.

If you run an agency or maintain a few dozen production sites, this is one of those reads that quietly changes what you put on next quarter’s plan. Here is what was actually said, and what I would do about it.

What is actually new

WordPress Core Committers met in person at WordCamp Europe 2026 in Kraków on June 5. Jonathan Desrosiers published the recap on the Make/Core blog on June 15. The meeting followed Chatham House Rule, so no individual is quoted, but the agenda and the conclusions are on the record.

Five things stood out.

One. The Gutenberg-to-Core sync is still painful. The build script that copies Gutenberg into wordpress-develop works, but it has edge cases, and the SVN svn:ignore properties drift away from Git’s .gitignore often enough to break commits. There is a Trac ticket — #64971 — to address that. The committers also flagged that the npm dependency handling that landed in 7.0 broke existing local workflows for some contributors. None of this is catastrophic, but it is the kind of friction that compounds.

Two. They are openly discussing a Chrome-style canary channel. The idea is feature flags plus experimental builds — not a replacement for the Gutenberg plugin, but a way to ship and test in-progress work without making it default for every site that auto-updates. The concerns raised in the room were the right ones: how do you communicate it, what happens to dependent code when a canary feature is removed, and where does PHP fit (the Gutenberg plugin is mostly JS, but Core is not).

Three. Beta testing is starvation-level. The recap puts it bluntly: the WordPress Beta Tester plugin has only about 3,000 active installs. That is the size of a small WordCamp, not the size of a CMS that runs roughly forty percent of the web. The committers floated merging Beta Tester functionality directly into Core so testing a beta becomes a setting, not a separate plugin install. The hard part, correctly noted, is database migrations that are not always reversible.

Four. Real-time collaboration is officially on a slower path. The group agreed with the May decision to remove RTC from WordPress 7.0. The new framing is that the underlying architecture probably belongs in Core, but the full Google-Docs-style feature set probably does not — at least not by default. One proposal: ship the WebSockets transport in Core and leave HTTP polling as an optional plugin. There is also an explicit ask to define acceptance criteria before reconsidering RTC for a future release, which is a much more honest conversation than the one we had a year ago.

Five. Some committers report they lost the ability to bypass PR checks on the Gutenberg repo on GitHub. No one has admitted to changing permissions, the WordPress Core team membership on GitHub is unchanged on the surface, but the symptoms are real. The recap is clear that “Core = Gutenberg, Gutenberg = Core” — SVN commit access to Core remains the gate for Gutenberg Core team membership, and that policy is being reasserted.

The recap also nods to two adjacent decisions you have probably already absorbed: the React 19 upgrade was temporarily reverted in Gutenberg 23.3.2 with a new strategy for WordPress 7.1, and the collaborative editing outreach effort for 7.1 opened public testing earlier in June. The committers’ meeting is the connective tissue under all of that.

Why it matters for WordPress and WooCommerce people

It matters because the operational reality of WordPress is now twenty years of accumulated production behavior layered on top of a much younger editor codebase, and the two move on different clocks. Core ships twice or three times a year. Gutenberg ships a plugin every two weeks. The recap is the project itself admitting that gluing those two clocks together is harder than it looks from the outside.

For agencies, three concrete consequences.

The first is that the React 19 story is not over. It was reverted because plugin authors had not caught up; it will land in 7.1. If your shop maintains a custom block library or a WooCommerce extension that hooks into the editor, the pre-flight checks you do on the 7.1 beta are not optional. The committers basically said in the room: communicate more, expect more. That cuts both ways. We have to read the dev chat agendas, and they have to write them.

The second is that real-time collaboration is now a long arc, not a feature you can promise a client next quarter. The architecture might land, the full feature set will not. If you sold a client on “editorial workflow with real-time co-editing in WordPress” off the back of the early 7.0 marketing, walk that back now. The honest answer is: a year, maybe more, and the shape will be different from what the demos suggested.

The third is that beta testing is now an agency responsibility, not a “someone will do it” problem. Three thousand installs of the Beta Tester plugin is, frankly, embarrassing. The committers know it. If a canary channel or merged-in Beta Tester ships in 7.1, the agencies that already run staging environments are the ones who should be feeding that pipeline. WordPress quietly wins for the same reason it always has — maturity, redirections, slugs that survive a rebuild, revisions, a plugin ecosystem with real governance. That maturity is upstream of the editor, and it depends on us actually testing the upstream changes before they reach a client’s site.

What I would do (or not do) about it

Concretely, three moves on our side at The WP Clan, and I would recommend them to any agency reading this.

Install the Beta Tester plugin on at least one staging clone of each critical client site, today. Not on production. Not next sprint. Today. Set the channel to “Bleeding edge” or “Beta/RC” and let it auto-update those staging sites. When 7.1 beta 1 lands, you will already be on it. If a regression hits a custom block or a WooCommerce flow, you will see it before it ships to a hundred million sites — including yours.

Stop selling real-time collaboration as a 2026 deliverable. If a client needs Google Docs-style co-editing in WordPress this year, the honest answer is “not yet, and probably not by default when it does land — it will likely be a Core architecture with a plugin layer on top.” Sell what is real: revisions, locking, role-based editorial workflow, scheduled posts. WordPress has shipped those for over a decade. They scale.

Read the Make/Core blog the way you read your monitoring dashboard. The recap from Kraków is two pages. The dev chat agendas are shorter. The React 19 revert post took five minutes to read and saved teams hours of speculation. If you are running production WordPress sites and you are not reading Make weekly, you are operating on rumor. The signal-to-noise ratio there is higher than on any “WordPress news” newsletter I have seen.

What I would not do is panic about the Gutenberg-Core friction. The committers are talking about it openly, in a room together, with a published recap. That is governance working, not failing. Compare it to almost any AI-coding-tool ecosystem this year, where the only “recap” you ever get is a tweet from a founder.

The pattern repeats: every new wave promises to replace the CMS, and every new wave ends up running on top of one. The WordPress wave keeps running because, in rooms like the one in Kraków, the people maintaining it still write down what they decided, and ship it.